Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


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

From: Alan Gutierrez <alan-xml-dev@-----.--->
To: Peter Hunsberger <peter.hunsberger@-----.--->
Date: 2/2/2005 2:37:00 PM
* Peter Hunsberger <peter.hunsberger@g...> [2005-01-31 10:51]:
> On Sat, 29 Jan 2005 10:02:17 -0500, Alan Gutierrez
> <alan-xml-dev@e...> 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


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent