<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1639164799743833&amp;ev=PageView&amp;noscript=1">
Classic vs. New Technologies in the CMS World
Diagram Views

Classic vs. New Technologies in the CMS World

Ektron, Code
Published by Joe Mayberry on 06.13.13

Everything was new at one point, and all new things
eventually become old. The trick is to know when to use the new thing, and when
to polish up something older and make it shine all over again.

Out with the Old, In with the New. Or is it the other way around?

Don’t you just love shiny, new things? There is something about the word “new” that gets everyone excited.

This tendency may be even more pronounced in the technology world. We constantly use terms like the “cutting edge”, for people who are using the newest technologies available, and the “bleeding edge”, where people are creating something new that has never been seen before.

But even with all of that sparkle and shine of the new, it’s the older, tried and true techniques that are the actual bread and butter of commercial web development. These are the methodologies that have a fine patina from regular use. They may not be as bright as they once were, but they are solid and dependable, and they’re what we are comfortable with.

Let’s take XSLTs (Extensible Stylesheet Language Transformations)
for example. This is one of those classic technologies that has been around for years, and will continue to be useful for some time to come (see my earlier blog post Old Tricks - XSLT files and Smart Forms, posted on the Ektron Community Blogs). But XSLT has fallen from favor over the last couple of years. People and companies have moved away from using it as widely as they once did.

In the Ektron development world, the technologies of the moment are the Templated Controls, as well as strongly typed APIs built from custom smart forms. These are powerful, up-and-coming technologies that everyone using Ektron needs to be looking at and using. These tools can provide a flexible way to present your data, and they work right in your .aspx pages, which means you’ll have fewer files to build and maintain.

However, for structured smart form content in Ektron, defining an XSLT file relationship in the Workarea that transforms the smart form XML is probably still the best solution, and one that we use here at Diagram on a regular basis to great effect. We also build content type APIs for some of the smart forms and use those in the ASP.Net code. One great use of this method is to provide an easy management interface for the site’s configuration settings. By building a .Net API from the smart form, we have easy access to those settings throughout the website’s code.
We are also starting to use some of the bindable ASP.Net controls for things like menus, an area that historically has been very XSLT driven.

So we have the old and the new, but which one is better? That’s like asking which is better, donuts or muffins? (The correct answer is donuts, but that’s beside the point.) In reality, it depends. Which one do you have in front of you? Does it have sprinkles? Which one are you most comfortable with? What are you trying to do? Pick the best solution for the problem, but keep in mind that that solution may change over time, and don’t be afraid to re-evaluate and make changes.

Everything was new at one point, and all new things eventually become old. The trick is to know when to use the new thing, and when to polish up something older and make it shine all over again.

 

Have questions or comments about this post? We'd love to hear from you.