[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Even if you're not ... was If you're going to the W3C meet
* Robert Koberg <rob@k...> [2005-01-29 11:02]: > 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. Say what? I'm not too keen on Ant. It's not the part of my work that I enjoy, that is. I don't enjoy the days spent resolving ClassLoader issues, for example. I'm pleased with XSLT as a solution to construction of Ant scripts, or the logic of ant scripts. I only want to use Ant for dependency resolution, not for decision making. In that sense, my system, which I call Mix is a project configurator. Mix is to Ant, as configure is to make. Except that is is, much, much, simpler, since it only supports JVM based languages and libraries. There is another thread about adding xpath syntax to find. If there was such a function library exposed to XSLT, then my build.xslt script wouldn't have to depend on an Ant task to generate an XML picture of (bits of) the filesystem. > - 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? :) That last bit makes sense. What everyone is suggesting is either one template to rule them all, or pipelineing, or a mixture of both. If I were to release Mix as open source, I'd bill it as a SoC tool, that simply generates Ant files that are deviod of build configuration logic, that only contain dependency resolution. Altough, I've found that even when I offer to do the work myself, that people have deep reservations against a pure Ant solution that is not, get this, Maven. In any case, open sourcing a configuration system, I don't know. Do you really want to troubleshoot other people's builds? -- 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
|