jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morgan Delagrange <morg...@apache.org>
Subject Re: Work on DBTags and XSL, release 2, and etcetera
Date Thu, 14 Jun 2001 19:32:30 GMT
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?  Some of the XTags
features you mention are also present in XSL rel2, and the others could be
merged in.

If you don't think that's a reasonable approach, I'd just as
soon deprecate the XSL tag library than have competing
implementations.  Maybe that's the way to go, but I suspect some people
just want to do transformations.  I suspect that the XSLT interface would
be stronger and have more contributors as a result, and I bet so would the
XPATH support.

- Morgan

On Thu, 14 Jun 2001, James Strachan wrote:

> Hi Morgan
> 
> From: "Morgan Delagrange" <morgand@apache.org>
> > James, I haven't taken a close look at XTags yet, but what would
> > you say to working on XSL, release 2 together and pointing XTags users
> > XSL.  Or maybe we could bundle them together?  It seems like we could gain
> > more momentum together.
> 
> XTags started life as being an implementation of XSLT in JSP custom tags,
> allowing JSP and JSP custom tags to be used 'inside' XSLT so to speak. So it
> initially focussed on parsing documents then using XPath to navigate and
> style XML.
> 
> For various reasons XTags gradually expanded to integrate full XSLT support
> as well. (e.g. you can parse a document, iterate over it using XPath then
> style part of it using a regular XSLT operation).
> 
> Currently the <xtags:style> tag implements XSLT in a similar manner to the
> <xsl:apply> tag and allows parameters to be passed in with <xtags:param>.
> Its currently based on JAXP 1.1 and can take a local resource URI, a URL, a
> DOM node, a dom4j Node or the text body for the XML or XSL. It can also take
> the current context too. So the following is possible...
> 
>     <xtags:parse url="http://foo.com/user.xml"/>
>     Hello there <xtags:valueOf select="/user/name"/>
>     <%-- now style the whole document with XSLT --%>
>     <xtags:style xsl="userAsHtml.xsl"/>
> 
> I had problems on a recent project using JAXP 1.1 inside WebLogic (WL 6.0
> SP1 can only use JAXP 1.0) so as a workaround I added <xtags:xalanStyle>
> which behaves just like <xtags:style> except it explicitly uses the Xalan
> API directly rather than JAXP 1.1. Hopefully this will be just a temporary
> work aorund and can be removed when all common Servlet engines can handle
> JAXP1.1
> 
> 
> So in summary I'd say my preference is to merge all XML operations and
> features into the same library if at all possible. Though this could confuse
> new users as there are already quite a few tags in XTags, so maybe a small
> 'XSLT only' library with just a few tags and then a full 'XPath and XSLT'
> library with many more tags might make sense?
> 
> Thoughts?
> 
> James
> 
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 


Mime
View raw message