Re: Even if you're not ... was If you're going to the W3Cmeeti
Alan Gutierrez wrote: > > Use the above to generate an Ant script. I run a transform and I > have javac, junit, javadoc, jar, svn, and distrubute tasks. > > How do I allow a user to plug in a new set of tasks to generate? > > This is a general problem I'm having, how do you create hooks, > callbacks, er, how do you create an XSLT framework? I do this type of thing with our content management system (http://livestoryboard.com) and I registered a domain (xslant.org, doesn't exist yet, but heh.., say it :) to (Open Source'dly) expose the things that you are talking about. I also use ant as an exit strategy for our app (you can take your project, edit XML in your fav editor and run an ant build to generate/promote your project/site). I use XSL to create JUnit/HttpUnit/Cactus tests based on an application configuration file. The app config file is also used to generate a standards compliant web.xml (2.3 or 2.4) and the HTML framework for our app. I have also made a few custom tasks for creating Templates, Transformer and URIResolver objects to be cached for run/build-time. I just haven't had time to create the xslant.org site... The way I have created an XSLT framework (think of websites, but can be anything) can summarized as follows: - you have a fallback set of XSL files in a manager app. For us it looks like: -- aggregator.xsl -- atom.xsl -- banner.xsl -- blog-post.xsl -- content.xsl -- flash.xsl (or flashturbation.xsl :) -- footer.xsl -- global_definitions.xsl (takes params and sets up global vars) -- head.xsl -- layouts.xsl (the primary XSL if not reproduced in a project) -- linking.xsl -- metadata_nodesets.xsl -- rss_2.xsl -- rss_091.xsl -- second-level-nav.xsl (usually right or left nav) -- table.xsl -- text.xsl (for ascii text output, requires special URIResolver) -- topics.xsl -- top-level-nav.xsl (usually tabs) - you have a project(s) that overrides/extends/uses the fallbacks. This usually only needs to redefine or extend(xsl:import) layouts.xsl and perhaps banner.xsl and footer.xsl. The layouts.xsl is usually the main project XSL that the client (usually we) have to deal with. It xsl:imports the files mentioned above and/or project specific files. I have a custom URIResolver for the Templates and Transformer objects. The templates resolver deals with XSL and the transformer resolver deals with document() calls. The resolver looks first in the project to resolve, if it can't find what it wants, it falls back to the manager app. What do I mean by redefine and extend? - Say you wanted a different way to totally change the way the HTML HEAD is rendered -- you would create a project specific head.xsl and do whatever you want. - Say you wanted to keep most of the functionality of head.xsl from the default/fallback -- you would create (perhaps) a head_ext.xsl which imports the fallback head.xsl and override certain templates. The default head.xsl has its entry template looking like: <xsl:template name="head"> <head> <xsl:call-template name="head-misc-before"/> <xsl:call-template name="head-css"/> <xsl:call-template name="head-favicon"/> <xsl:call-template name="head-metadata-misc"/> <xsl:call-template name="head-metadata-dc"/> <xsl:call-template name="head-title"/> <xsl:call-template name="head-misc-after"/> <xsl:call-template name="js_setup"/> </head> </xsl:template> (you could look at the source of our site to see how it gets rendered) Does this makes sense? (am I rambling? :) best, -Rob > > -- > Alan Gutierrez - alan@e...
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format