I have to admit that when I first heard of this potential paradigm shift was skeptical to say the least. How would this help me with the projects I was working on? Why should I even consider making this change? I did not see any advantage in putting in all kinds of logic in my velocity code to make this possible. Well let’s just say that I am often guilty of “if it ain’t broke don’t fix it” train of thought. Sometimes that mindset works. Not so much when it comes to technology. I mean back in the day we used punch cards, VCR’s for hard drives, and FORTRAN! Ouch!!! (I think I just really dated myself) I wouldn’t want to still be doing things that way any longer.
So I began giving this topic much thought and over the last couple of years discovered that there are a number of very good reasons to make this shift in coding – even if your end users don’t see it!
The first benefit I began to realize was it made me a better coder because it necessarily created greater reuse. I could now make use of macros in such a way that it made sense to have a file of like use macros and reuse from template to template within a single project and then from project to project. It forced me to start making functions more generic and thus more widely used. Great benefit to me over the way I was originally taught to code in Cascade!
The second benefit I began to notice was with macros built in velocity that I was reusing heavily, I could now pass error messages in such a fashion as to greatly expand the content creator’s experience. For example, by using internal and external views I could easily and boldly display error messages within Cascade that would alert the content creator to insufficient content for the desired output but not affect the published page that your site visitors would see. I could also easily maintain all error messages in a single location and not have to bounce around trying to find out where I created this error message or that error message. Streamlining! It now encourages the developer to supply this extra interaction with the content creator which in turn creates a better end user experience through better crafted content. Win – win – win!!!
The third and final benefit I will discuss in this post but certainly not the last benefit realized through paradigm shift is greater flexibility building content. The module structure of your velocity code will allow you the ability to create an interface that allows your content creators tremendous flexibility in just how a page gets built out. What do I mean by this? Well, let’s say a standard template is built today that contains the following structure:
Under the old multiple template method every page built with this template would always be laid out EXACTLY like this. The “default” template block that we are required to have would be mapped to a specific data definition that would build our desired layout. No exceptions except maybe to skip a section that we don’t want to display but I could not for instance choose to display the “tabbed content section” immediately after the “banner / slider section” or display the “2-column content section” before the “full width content section”. I think you are getting the idea. We would have to create a new template for each of these “new” desired layouts. However with the “section” tag in CSS and Cascade Server’s data definitions, templates, etc., we can now employ velocity to create a whole new way of building content.
Let’s consider the single template process. First, we would create a new macro to build each of these sections independently of the other. Then by modifying our data definition would could create a system whereby the content creator selects the desired section type in the order they wish to display them. Now I know exactly what you are thinking. “Bill that is chaos. I can’t allow my content creators to have that much control – I mean we paid large sums of money to come up with the approved designs and now you want me to let people just wrec havoc on our designs!” Well not exactly. See you still have 100% control of the content output possibilities – you are just offering up a bit of flexibility to your content creators. This flexibility helps them feel important and causes them to have greater buy in to Cascade Server. Greater buy in and feeling important makes your users want to create great content! Everyone wins!
Ok, let’s get back to just how this magic happens. Obviously you wouldn’t want complete freedom to move the page around. I mean the header should always be first. The footer should always be last. So we don’t allow the flexible template to allow positional changes to these blocks. We only allow the flexibility for the sections where it makes sense and will not detract from the site design. It would look something like this:
They only get to have the ability to change the order or quantity of content types in the flexible content section above. I mean wouldn’t it be nice to allow them to put 3 separate full-width content sections after each other where the data definition prompts them for each piece of content and thus controlling the final style being output instead of having a single textarea that they try to create all of that content within? Or worse, it is determined that this is important enough that they come back and request a whole new template to handle this “change” in template output!
This is just a brief overview of some of the benefits of using flexible single template designs in your Cascade Server sites.
ArcticSoft has been working with Cascade Server for nearly 10 years. ArcticSoft has experience in both developing and managing Cascade for large organizations in higher education, not-for-profit, and industry. ArcticSoft is experienced in training for Cascade Server (both onsite and virtual) as well as creating custom training to meet your organization’s specific needs, whether it is for end users, content creators or internal developers. ArcticSoft is experienced in designing, developing, and integrating any size website into Cascade Server.