[
Lists Home |
Date Index |
Thread Index
]
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@engrm.com
|
