Using syntax in an umbraco document template and in XSLT templates

November 18th, 2006 | Tags: , , ,

I am about to embark on a project that will be using ASP.NET AJAX extensively, along with the ASP.NET AJAX Control Toolkit. I would love to be able to do the whole thing inside of Umbraco, but, as far as I know, the only way to use these controls is from within a macro.

For example (very simplified), I have a list of items that I want to display. Each item gets a delete button. I would like to put each item into an updatepanel and so when the delete button is clicked, the item simply disappears. There is no need to reload the entire page when we are just changing one small portion of it.

Right now, my options would be to put the entire list inside a macro or write all the ajax myself (which seems like a step backward).

I forgot to mention that the list is based on nodes and so here is my preferred way of doing things: Generate the list using xslt, like I would if I didn’t need the controls, and have the xslt output the controls as you would expect to see them in an aspx page. They are, after all, well-formed xml, and so I see no reason why this wouldn’t work if the umbraco parser could then translate these controls into objects, like it does for <?aspnet_form>. Except that it doesn’t have to (why reinvent the wheel?), but more about that later.

I’ve been perusing the umbraco source code, and this is how I understand parsing works (high-level view and leaving out a lot of details like caching). It gets the page template and replaces all the values from the specific page node. Then it renders the macros. Then it finds a few specific items like the aspnet form. All the while it is keeping all the data inside a Page by just adding sub controls to that Page’s control collection, the majority of which are LiteralControls.

What if instead of doing that all the parser did was build a string. It would still replace all the getitems with the values from the specific node. It would still replace all the XSLT macros with their transformed renderings. In short, it would still need to process anything that started with <umbraco, but instead of building a page control hierarchy out of that it would simply build a string. But it wouldn’t be an ordinary string, the string would contain exactly what you would expect to find in an aspx page. Then the umbraco parser would just pass this string on to the parser to render the output.

Did the flexibility and usefulness of Umbraco just expand infinitely? Maybe not, but I’d say at least exponentially. Obviously there would be kinks to work out, but wouldn’t it be worth it? Imagine the possibilities of your page templates being aspx pages and your xslt transformations including controls.

Doesn’t this sound feasible and well worth the effort? Prove me wrong; tell me I’m crazy and I’ll shut up ;-)

  1. Scott
    July 31st, 2008 at 21:58
    Reply | Quote | #1

    That’s pretty much how the CMS I wrote worked. I figured you’ve got a whole functionality engine already, all you need to do is allow a meta controls layer on top of that… never finished it but it was pretty cool.