On Tuesday 7 February 2006 2:04 pm, Robert Koberg wrote: > I was just curious if this needs to be dynamic. Couldn't you pregenerate > all these things? This is what we do for our CMS. CMS users select > layouts for pages (or falls back to an ancestor that had a layout > defined). Several content pieces or XML components can be assigned to > defined regions on a page. CMS users can choose things at the folder > level like should a snailtrail or paging information show. We use XML > configuration, content and XSL to transform to a static file. That file > can be a velocity page, just as much as possible is pregenerated. > > I guess in other words, it sounds like you want to build a CMS.
well, I think we would certainly like this to be a part of a broader CMS project. At present we do almost exactly what you do: we use XSL to transform XML - first into 'xml snippets' (that roughly correspond to the content 'entities' we would want to create Velocity Tools for), then into a static HTML files. Subsequently, Velocity is used to pull these static HTML files in to various points on a page. What we want to do is use Velocity to overcome the problems inherent to this approach; which are: 1. If the design or layout of things changes, or even if we just change the content a little, we have to 're-rip' stuff (run through the XSLs). With the amount of content we have, and the frequency of changes, this is a burden. 2. Authoring XSLs requires a certain expertise and knowledge of the XML formats we use; authoring Velocity templates requires very little. We can produce XHTML Velocity templates very quickly which produce standards-compliant, accessible code. However, we hit a bottleneck (and a significant source of errors) when parts (or all) of these templates need to be written as XSLs. 3. As with most organisations, our design team is responsible for all the HTML, CSS, Javascript etc that is used to display pages under normal circumstances; and our development team is responsible for everything else. The static-file approach you mention requires extensive interaction between these departments that is a source of delays and errors. What we need to do is get rid of the stage where XSLs are producing HTML. By making Velocity Tools that retrieve data associated with content 'entities' (whether from 'xml snippets' or a database or wherever) and insert this into the context in a standardised, pre-agreed manner, rebuilding, xsl editing, and inter-departmental coopertation is not necessary every time there is a change in the appearance of a site etc ... So, yes - it is certainly related to content management, but Velocity Tools in themselves would not be a CMS! :D Chris ******************************************************************************** DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS ******************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
