This post is part of a series, this being the third part, if
you're interested,
read the first part here, and
the second part here.
In Umbraco, when rendering the UI, the standard ASP.NET approach
with MasterPages apply. However, from there on, there are several
different approaches, including standard .NET controls, custom
WebControls, custom UserControls, (in 4.1 there is LINQ support),
and finally, XSLT. To many developers XSLT is like the bastard
sibling you never want to meet, but once you get around that "I
don't know you, so I don't want to play with you" feeling, it's
actually a very powerful tool for presentation. Since it's a fairly
brutish language, it can't "operate heavy machinery", but that's
where the combo Umbraco - XSLT really stands out. By enabling you
to add your own code to the XSLT processing, through XSLT
Extensions, you can do pretty much whatever you want with your
data. Those are the calls in the XSLT that begin with
"umbraco.library" (built-in), or "xsl.lib" (my own). To all you MVC
fans, yes, that would be like doing logic in your view, and yes,
that's a big no-no, I'm saying you can, not that you should. (Yes,
I know, I do in the examples.). But I digress.
When rendering the application UI to the client, I've used
MasterPages and POSH (Plain Old Semantic Html) up until the step
where the users selects which material the would like to modify. I
use XSLT to render the list of campaigns, and the list of
materials, but that's just lists with links. Once the user selects
a material, it's all JavaScript. I want my application to be a
smooth user experience, and not something that'll make them call
the marketing department asking what the hell they were
thinking.
In most cases, XSLT is used to render markup, however, I've also
used it to render the JavaScript used both for the editor controls,
as well as for the preview. Since each material is unique, the
basis for how they should work is shared, but the implementation is
specific. The real XSLT is fairly large, and thus hard to show
here, but I've provided snippets that explain the jist of
thing.
In the image above, you can (hopefully) see how I iterate all
child objects, rendering the JavaScript object implementation code.
I've shortened the example for brevity, omitting most of the
variable declarations, but if you really want to see the whole
shabang, get in touch, and maybe I'll share :). There are two more
parts, the jQuery preview code, and the editor control code, but
we'll get to those soon enough. Maybe you're wondering why the hell
I have two JavaScript objects for each region? Well, one, what I've
chosen to name the ClientObject, is used as a data carrier in
communication with the server, and the jQuery object is used in the
editing and previewing on the client. Yes, I could use the jQuery
object for both, but this way is faster. Not in terms of
performance, but rather in terms of me not having to think or care
so much. Although this is another discussion completely, let me
just say it. I really want to do the best solution possible, but I
have yet to meet the client willing to pay for that, most clients
settle for "Does it work?" (in some cases even for "Does it
compile?", but let's not go there.)
So, in the sample above, I create a DOM element, with a wrapper
function called createElement, it has a signature like this:
createElement(tagName, id, style, text). What the XSLT template
does is, it creates a DOM element, and if the editor has tagged the
region as moveable, registers it as draggable (jQueryUI), it also
retains its original position as data on the DOM element, so that
it can easily be reset. The example above is for a text element,
either a Formatted or Simple Text. In the case of a text element,
the different available font sizes are saved as data on the DOM
element as well.
Finally, we render the editor controls, enabling the user (if
allowed by the editor), to modify different aspects of a region.
I've shortened it a bit here as well, but it shows the general idea
anyway, in this case, it's a Simple Text Region.
And this is what it looks like. On the left are the editor
controls, on the right, the preview controls, and in the browser
memory, a JavaScript object structure representing what you see,
and any changes that you have done. As soon as I can get my son to
sleep longer than 45 minutes at a time, I'll try to write the next
part, as this post has been written, sporadically, over the course
of the past six and a half hours.
Next up:
Sending modifications to the server.