Subject: Re: XSL and xml entities that need to be translated From: Mike Brown <mike@xxxxxxxx> Date: Thu, 18 May 2000 13:38:52 -0600 (MDT) |
> we are a large shop and we need a way of letting multiple content editors > create and edit the content of a site. We are creating > user-friendly/wysiwig tools that read and write XML/XSL. We have chosen XML > as our breaking point between client-side and server-side development > efforts. We are trying a modular structure so many people could possibly be > working on the same page, just different screen sections. Screen sections > are represented by DIVs (4th gen +), TDs (3rd gen +) and rect(l,t,r,b) (Macr > Director). In each screen section we would place the results of an XSL > transformation It sounds like you have a clear understanding of the design patterns you need. I solved similar problems for my company's site building product by using several XML and XHTML documents to define structural and presentational data, one XML document for content data, a fairly complex stylesheet to pull it all together, and an XML document to control what the stylesheet does in each site-building session as well as pointing to where to find the necessary data documents. The XSL acts on the control file and uses the document() function to pull in all the additional data that it needs. The XSL itself is split up into a couple of files to divide core from customer-specific templates, but it doesn't have to be. There are templates to handle processing the control file, templates to walk the structural data tree, and templates to produce (X)HTML using either XHTML docs as the basis for an identity transform, or using custom logic to produce more complex components (screen sections). At insert points in the XHTML docs I have elements in a private namespace, corresponding directly with elements in the structural data document. The XHTML doc itself also corresponds to an element in the structural data doc. It's quite modular but also imposes a lot of requirements on the system that manages and produces all the XML that is needed. The nice thing is that you can maintain a library of reusable components that can be combined in many ways just by modifying simple documents and regenerating. You also have pretty much an entire site described in XML. One better would be to use Cocoon's approach, which would XMLize the logic even further. However the modularity of the site building code itself is not that big of an issue once you quantify and componentize as much of the structural and presentational data as you can. I may be demonstrating a lack of understanding of Cocoon when I make that assertion, though. - Mike ___________________________________________________________ Mike J. Brown, software engineer, Webb Interactive Services XML/XSL stuff: http://www.skew.org/ http://www.webb.net/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL and xml entities that need , Robert Koberg | Thread | Re: XSL and entities, Sebastian Rahtz |
Re: apply-templates and Ful XML Pat, Mike Brown | Date | Re: Netscape Support for XSL, Matt Sergeant |
Month |