This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSL and xml entities that need to be translated


> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]