Re: XSLT Reuse (Was: Even if you're not ... (Was: If you're going to the W3C meeting in March))

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Peter Hunsberger <peter.hunsberger@gmail.com> [2005-01-31 10:51]:
> On Sat, 29 Jan 2005 10:02:17 -0500, Alan Gutierrez
> <alan-xml-dev@engrm.com> wrote:
> 
> <snip/>
> 
> >    I'm not sure how to ask the question. Let's say you have a file
> >    that's a project.
> > 
> >    <project>
> >      <source>
> >        <name>main</name>
> >        <dir>src/main</dir>
> >        <category>dist</category>
> >      </source>
> >    </project>
> > 
> >    Project directory:
> > 
> >      /project
> >          /src
> >              /java
> >              /resource
> > 
> >    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?

> One way to do this would be to make it data driven.  In the framework
> class you build some variable that is the master list of tasks and
> some well defined calls to initialize the list and then process it. 
> Any framework class can then modify the list as needed and then pass
> control back.  Eg, in the framework:

> <xsl:variable name="tasks">
>  <javac/><junit/><javadoc/><jar/><svn/><distrubute/>
> </xsl:variable>

> <xsl:template name="init">
>   <xsl:apply-templates select="tasks" mode="process/>
> </xsl:template>

> Then the users of the framework implement "init" with a higher
> priority and call the same modal templates. They add their own task
> specific templates with the same mode as needed.  Of course, with this
> approach you're also likely looking at adding some parameter that is
> the real data to be passed from the main call, to the init and then on
> to the processing tasks....

    This system is building Ant files. I've reduced my Ant needs to
    dependency resolution.

    To start with, if antlr needs javac, it is on the developer to
    know this, and request both task definitions. There is no fancy
    include mechanism that resolves dependencies.

    Then it becomes a matter of sorting out the dependencies. I'd
    like an antlr task, when it generates it's targets, to be able
    to say that javac now dependes on antlr.

    This is something to solve in XSLT.

    My first attempt will be to generate an ant file that looks like
    this:

    <project name="foo" default="java">

      <target name="antlr">
        <dependant>javac</dependant>
        <antlr grammar="src/main/antr/Foo.g"/>
      </target>

      <target name="javac">
        <javac srcdir="src/main/java/**/*.java"
               destdir="var/classes/main/classes"/>
      </target>

    </project>

    Then, and here I'm using a pipelineing approach, I'd run an XSLT
    transform that would make it look like this:

    <project name="foo" default="java">

      <target name="antlr">
        <antlr grammar="src/main/antr/Foo.g"/>
      </target>

      <target name="javac" depends="antlr">
        <javac srcdir="src/main/java/**/*.java"
               destdir="var/classes/main/classes"/>
      </target>

    </project>

    Which ought to be simple enough.

    Basically, the antlr XSLT will add dependencies to the javac task.

    That's about all I think I need to worry about for extensiblity
    in this particular problem.
    
    So maybe one way to solve XSLT reuse is through pipelining and
    the generation of intermediate documents.

-- 
Peter Hunsberger