From: "Morgan Delagrange" <[EMAIL PROTECTED]>
> On Mon, 18 Jun 2001, James Strachan wrote:
>
> > > I think I'd prefer having XSLT operations inside a different package
than
> > > XPATH operations. XPATH isn't part of JAXP, so your XPATH
> > > support introduces additional dependancies that aren't strictly
necessary
> > > for transformations (e.g. dom4j). My preference would be to work on
> > > seperate tag libraries that complement one another. Is there anything
in
> > > your tag library that would prevent this approach?
> >
> > Yes. I want to be able to combine XPath and XSLT operations together-
such
> > as to style a fragment of a document - so the XSLT tags in XTags are
> > dependent on the XPath engine (dom4j right now).
>
> Guess I don't follow here. You're using JAXP to do your transformations,
> right? So any transformation you're doing inside your current taglib, it
> should be possible to do in another taglib. I'd be OK with
> building support for DOM, dom4j, etc. objects into the XSL taglib, if
> that's what it takes. Perhaps we can do some creative organization of the
> classes to avoid runtime dependencies.
I don't think I explained myself very well. JAXP does the transformation,
the difference is where the XML and XSL come from.
The <xtags:style> tag is dependent on both DOM and dom4j as the XPath tags
can be used to select a fragment of a document to be styled via XSLT or the
tag can take dom4j or DOM objects as the source (or stylesheet) to be styled
via JAXP.
e.g. following example uses both XPath and XSLT on the same document
instance...
<xtags:parse url="http://www.something.com/book.xml"/>
title <xtags:valueOf select="/book/title"/>
<xtags:forEach select="/book/overview">
<%-- only use XSLT if we've an overview --%>
<xtags:style xsl="overviewAsHtml.xsl"/>
</xtags:forEach>
<xtags:forEach select="/book/author">
authored by <xtags:valueOf select="name"/>
</xtags:forEach>
So the <xtags:style> tag has both compile time and runtime dependencies on
both the DOM interfaces and the dom4j interfaces.
If this isn't a problem we could share the same code across both XTags and
XSL - it could be the same library just with 2 TLDs or something.
We could try refactor most of the code from <xtags:style> and <xtags:param>
tags (and the backwards compatable <xtags:xalanStyle> tag for use in JAXP1.0
containers) into XSL without the DOM or dom4j dependencies, then XTags could
derive from the XSL implementations.
Though I'm not sure its worth it. The support for XPath has made the
implementation logic quite different I suspect (e.g. the logic of
doStartTag() and doEndTag() are quite different in the XTags version to what
I remember of the XSL version). So it could be more trouble than its worth
reusing. Calling a transformation with JAXP is mostly glue code anyway so in
this case I'd prefer an easy life than resusing 20-50 lines of code. (e.g. I
can imagine the <xtags:style> tag getting quite brittle if it derived from
the <xsl:style> tag and someone changes <xsl:style>).
>
> >
> > > Some of the XTags
> > > features you mention are also present in XSL rel2, and the others
could be
> > > merged in
> >
> > Due to the XPath dependencies (e.g. dom4j) its probably best if we keep
> > these 2 libraries seperate for now.
> >
> > XSL rel2 for just JAXP based XSLT
> >
> > XTags for XSLT + XPath and the rest (<xtags:forEach>, <xtags:valueOf>
> > <xtags:choose> / <xtags:when> /<xtags:otherwise> and so on).
>
> I'm OK with that, if we can finagle it so that your XSLT logic is
> literally driven by the classes in the XSL tags. I think it's overkill to
> have competing implementations within the same project.
>
> If we note on the XSL page that the classes are also included in XTags,
> then both projects benefit, I would think. Maybe I should experiment a
> little with that. Creating larger tag libraries from slices of more
> focused tag libraries is an appealing concept to me.
Agreed. Certainly aligning the tag libraries would make sense I think and
from a documentation perspective both libraries should cross reference each
other. We could try agree on the semantics of the tags so they look and feel
the same, even if the implementation differs somewhat. From an
implementation perspective it will probably be much easier to keep them
seperate though I think.
>> > I'd prefer to just have one tag library for working with XML which
included
> > XPath and XSLT really but I agree that some may wish to only depend on
JAXP.
> >
> I could be talked into that, as long as they're using overlapping
> code. Otherwise, I would rather drop support for the XSL taglib. You're
> tags are more mature than rel1, and rel2 is just on a branch and therefore
> relatively hidden from the users for now.
One day maybe JAXP might fully support XPath so this might not be much of an
issue. Until then keeping both libraries and aligning them closely would
make sense I think.
For sure rel1 should be replaced by rel2 then we could try aligning the XSLT
tags so they behave the same?
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
