Hey all,
Good news, I have a proof of concept of this idea actually working! It runs
as a fairly simple Ant task and it is SO much cleaner and easier to use than
XSL it is silly. It still embodies 100% of the general concept that XSL
tries to inflict on people. :-)
It works by building up a JDOM Document object of your .xml file and placing
that into Velocity's context. There is then a .vsl file that gets processed
by Velocity. Within there, it is very similar to a XSL file. You create
velocimacro's that reference the portions of your XML document as needed
through JDOM's Document API. This is very similar to XSL's
<xsl:apply-template match=""> functionality but it is actually quite a bit
more powerful and easy to use and understand. The output of the processing
of the .vsl document is then saved as standard HTML files.
The cool things is that the recently added Velocimacro's are really proven
as a "good thing" given that what I'm working on is heavily dependent on
them.
I also think that this will turn out to be substantially faster than Xalan
as well. This means that we could actually incorporate something like this
into Turbine or another framework (ie: cocoon) for building dynamic websites
using the XSL concepts, but without the XSL overhead and slowness.
I'm still trying to resolve some issues and bugs with Velocity that I'm
hitting, but Geir is working with me on it...so, once those are resolved, I
will clean up my code some more and post it for everyone to have fun with.
:-)
This is very cool.
-jon
on 11/21/2000 10:49 AM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
> It would have to be $sort_select or something like that and it would be
> #macro instead of #template_match.
>
> Ok, I spent a lot of time dreaming about this last night and I think I have
> a pretty good handle on what it would take:
>
> An Ant task to do the following:
> gather a list of .xml files to process
> passed in a .vsl (instead of .xsl) template for the processing
>
> the task would then use JDOM to build up an object representation of the
> .xml file which would then be put into velocity's context and made
> available to the .vsl file.
>
> Then, the Ant task would execute the .vsl page using Velocity and that page
> would work from top to bottom in execution. Within the page would be
> #macro's similar to the above one. The page would execute against the JDOM
> object in the context and do the substitutions there. You could refer to
> your specific objects like <body> from within the object in the context to
> get the values.
>
> With the recent addition of Velocitimacro's I think that this is going to
> make the .vsl page look and work excellently and be very similar in concept
> to a .xsl page.
>
> So, I think that I have a way to get 100% (and actually more because of the
> ability to stuff whatever I want into Velocity's Context object) of the
> functionality of XSL, but without ANY of the headache.
>
> On top of it, I can do stuff within the Ant task such as only process the
> files which have changed by comparing the timestamp of the .xml file with
> the timestamp of the output file and if it has changed, then only
> process/output as necessary.
>
> Summary: Essentially, I'm replacing the Xalan bit with Velocity. The entire
> overall big picture concept of XSLT execution is still there.
>
> Comments? Someone want to help me code this up? :-)
>
> thanks,
>
> -jon
--
twice of not very much is still a lot more than not very much
