[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Implementing an Blogger-style template using XSLT

• To: "publicreg@n..." <publicreg@n...>
• Subject: Re: Implementing an Blogger-style template using XSLT
• From: "Peter Hunsberger" <peter.hunsberger@g...>
• Date: Tue, 21 Feb 2006 08:33:03 -0600
• Cc: xml-dev@l...
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VbF6n9SuUE8OiIZqWRGrehJeZRsRa17/gcln0LCGa7o6Y89iUIOBA+YlijoUTk1KykB3WRXsjFb6mC3HzHZZLDTB68Sqk+Mq0egDI2x1C2nGwIzXHqELPumCkQg1Rfc/95jlCYnJ/8dlctQw1FiaJ7a7DBNcCjoY7J7VOE1sV9Y=
• In-reply-to: <38049.202.190.116.215.1140504403.squirrel@w...>
• References: <38049.202.190.116.215.1140504403.squirrel@w...>

On 2/21/06, publicreg@n... <publicreg@n...> wrote:
> Hi,
>
> I'm trying to implement a Blogger-style templating system and would like
> to get some feedback on whether it's feasible or not. While it's true that
> an XSLT file itself would be a template, some of my users are not keen on
> learning it and I'm trying to strike some middle ground here.
>
> The premise is this:
>
> The template file would be an extension of XHTML and looks like this:
>
<snip/> -------------------------
>
> Then, the data input would come in the form of an XML document that looks
> like this:
>
><snip/> --------------------------
>
>
> Finally, I'd have an XSLT file that uses the 2 files and then translates
> into XHTML code that I can output to the browser.
>
> How, folks? Do you think it's feasible to do this? Would appreciate any
> pointers in the right direction.

I've used essentially this architecture since the days when XSLT was
still a draft standard.  It works very well and with proper design can
have good performance. (Proper design includes many forms of caching.)

Currently we use Apache Cocoon to drive this which gives us a lot of
capabilities, many of which we don't really exploit.  It's probably at
least worth looking at.  In particular you can exploit pipelines to
break complex XSLT down into multiple transformations which often
makes hard XSLT problems a lot easier to code (you don't have to build
up complex variables and re-parse them for some problems) and you can
aggregate multiple XML sources to make context sensitive parsing much
easier.

Depending on your eventual deployment targets (cell phones, print,
other devices?) you may want to go a little more abstract than XHTML
for your mark up language.  XUL, XFORMS or something proprietary
perhaps.Among other things you might be able to keep the language
simpler and easier for the end users; and you can maybe separate the
presentation details from the markup model.

In our case we use a very abstract model and two main XSLT passes. 
The first creates an abstract combined model from the layout model,
the data, authorizations and other context dependant things (eg. do
you need internationalization support?).  The output of smashing all
these things together is still an abstract object model, but one that
maps pretty directly to output, minus any presentation device specific
details.  Depending on the deployment target a second transformation
then takes care of the specific presentation details.

I'd note that you should also plan on exploiting the capabilities of
CSS.  Depending on your needs it might be possible to do everything in
pure XML and CSS in which case things can be a lot simpler.


--
Peter Hunsberger

• References:
  • Implementing an Blogger-style template using XSLT
    • From: publicreg@n...

• Prev by Date: Re: Preferred object to xml mapping tool?
• Next by Date: RE: Preferred object to xml mapping tool?
• Previous by thread: Re: Implementing an Blogger-style template using XSLT
• Next by thread: [ANN] xnsdoc 1.1 - XML Schema documentation generator
• Index(es):
  • Date
  • Thread