Symphony.

Another benefit of a page ‘header’ file could be keeping a fingerprint of a datasource inside and getting Symphony to flag the page if the datasource fingerprint doesn’t match.

Why is this useful? Sometimes you’ll update multiple pages and datasources on your local box and then forget which datasources you changed when you copy to LIVE, if you indeed changed any. Having Symphony flag which pages require newer datasources would really help the workflow.

Man, take the weekend off and I miss all sorts of interesting stuff. My $.02:

• If you’re making Pages into classes, would this get us closer to having ‘template’ pages. Duplicating everything but the URL for my ‘static content’ Pges just rubs me the wrong way. It would be awesome if I could extend my ‘static content’ Page class with just the specific URL that it is being used in.

• Alternatively, if you do put the page data into the xsl, why not just have it as non-parsed xml rather than a comment? Not to go off the XML deep-end, but you could even implement a ‘template Page’(the same function as above) using xml as well by pointing to a common external xml file that defines your page type (i.e. common page DSs, url-params, events).

I kinda think Symphony encourages going “off the XML deep end”. That’s definitely not a bad thing ;)