You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by Morgan Delagrange <mo...@apache.org> on 2001/06/13 23:13:30 UTC
Work on DBTags and XSL, release 2, and etcetera
Hi all,
I just wanted to give y'all a heads-up that I'm going to review some
patches and such to DBTags and XSL that have been contributed over the
past couple of months. If you don't see your patches being addressed over
the next few weeks, drop a note to the list.
I also want to resume discussions on binary releases. This is for
perfectly selfish reasons, since I can't really merge in the release 2 XSL
tag library until release 1 has been committed to posterity.
Finally, if you're already a committer and would like to contribute, feel
free! 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.
- Morgan
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Eduardo Pelegri-Llopart <Ed...@Sun.COM>.
You can also bundle +1 TLD in the same JAR file; this lets you organize
the tags into two separate namespaces while keeping a single JAR
object. THat is a JSP 1.2 feature, but, given the situation at J1, it
seems that many vendors are just waiting for J2EE 1.3 to go final to
release their products.
- eduard/o
James wrote:
> 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?
James Strachan wrote:
>
> Hi Morgan
>
> From: "Morgan Delagrange" <mo...@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
merging XTags and XSL taglib (was Re: Work on DBTags and XSL, release 2, and etcetera)
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Morgan
From: "Morgan Delagrange" <mo...@apache.org>
> On Thu, 21 Jun 2001, James Strachan wrote:
>
> > > I think the issue of one or two tag libraries is pretty moot, now that
we
> > > can communicate changes via the news section (and of course the
mailing
> > > lists). If you'd prefer to deprecate the XSL taglib and build out
XTags,
> > > I'm cool with that, as long as the code is relatively clean; we want
to
> > > encourage ppl to contribute even if the XPath is not interesting to
them
> > > (and, of course, vice versa)!
> > >
> > > I'd be nice to work on a taglib where I'm not the sole maintainer. :)
> >
> > Me too! :)
> >
> > How about as a start I split out the source for the XSLT only tags into
a
> > seperate package so its easier to figure out whats going on then you
take a
> > look and see what you think and see if there's any features or behaviour
in
> > the XSL (rel1 and rel2) that are worth keeping or combining?
> >
> > James
>
> Sounds great.
OK now all the XSLT based tags are in a package
org.apache.xtags.xslt.*
XPath related tags are in
org.apache.xtags.xpath.*
The xtags library now conforms to the latest jakarta-taglibs build.
Currently it maintains backwards compatability with servlet engines that
cannot support JAXP 1.1 such as WebLogic 6.0 via the <xtags:xalanStyle> tag.
This requires the xalanj1compat.jar from the Xalan 2 distribution. This tag
will be deprecated once we have some stable releases available.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
On Thu, 21 Jun 2001, James Strachan wrote:
> > I think the issue of one or two tag libraries is pretty moot, now that we
> > can communicate changes via the news section (and of course the mailing
> > lists). If you'd prefer to deprecate the XSL taglib and build out XTags,
> > I'm cool with that, as long as the code is relatively clean; we want to
> > encourage ppl to contribute even if the XPath is not interesting to them
> > (and, of course, vice versa)!
> >
> > I'd be nice to work on a taglib where I'm not the sole maintainer. :)
>
> Me too! :)
>
> How about as a start I split out the source for the XSLT only tags into a
> seperate package so its easier to figure out whats going on then you take a
> look and see what you think and see if there's any features or behaviour in
> the XSL (rel1 and rel2) that are worth keeping or combining?
>
> James
Sounds great.
Morgna
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by James Strachan <ja...@yahoo.co.uk>.
> I think the issue of one or two tag libraries is pretty moot, now that we
> can communicate changes via the news section (and of course the mailing
> lists). If you'd prefer to deprecate the XSL taglib and build out XTags,
> I'm cool with that, as long as the code is relatively clean; we want to
> encourage ppl to contribute even if the XPath is not interesting to them
> (and, of course, vice versa)!
>
> I'd be nice to work on a taglib where I'm not the sole maintainer. :)
Me too! :)
How about as a start I split out the source for the XSLT only tags into a
seperate package so its easier to figure out whats going on then you take a
look and see what you think and see if there's any features or behaviour in
the XSL (rel1 and rel2) that are worth keeping or combining?
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
I think the issue of one or two tag libraries is pretty moot, now that we
can communicate changes via the news section (and of course the mailing
lists). If you'd prefer to deprecate the XSL taglib and build out XTags,
I'm cool with that, as long as the code is relatively clean; we want to
encourage ppl to contribute even if the XPath is not interesting to them
(and, of course, vice versa)!
I'd be nice to work on a taglib where I'm not the sole maintainer. :)
- Morgan
On Wed, 20 Jun 2001, James Strachan wrote:
> Hi Morgan
>
> From: "Morgan Delagrange" <mo...@apache.org>
> > > 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.
> >
> > All that sounds like useful functionality for the basic XSL tags as
> > well. That's why I want to avoid two sets of classes. (XTags does this
> > but not that, XSL does that but not this.)
>
> If the dependence on dom4j and DOM is not an issue right now, I'd love us to
> combine our efforts into a single library.
> So lets do it. If the dependency ever becomes a real issue we can revisit
> this decision. I'm sure there are ways to at least minimise the dependency.
>
> > > So the <xtags:style> tag has both compile time and runtime dependencies
> on
> > > both the DOM interfaces and the dom4j interfaces.
> >
> > I don't think I have a problem with adding that to XSL, if that's what it
> > takes to bring the implementations together.
>
> Cool.
>
> >
> > > 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.
> >
> > Sure, that's what I think is best.
>
> So either we have a single taglib or we share the same code over 2 TLDs,
> 'just XSL' or 'XSL + XPath'.
> Which would you prefer? For simplicity and consolidation (just 1 web page, 1
> set of documentation, 1 TLD and so on) I'd prefer one library though I could
> be persuaded either way.
>
>
> > I'd like to peek at it and see if it's possible to remove non-JAXP
> > dependencies at runtime (don't care about compile-time); other project
> > have managed similar tricks. But if it's prohibitive, I'm willing to
> > increase the XSL dependencies in order to remove the duplication of
> > effort.
>
> I think its prohibitive right now but something we could address in the
> future.
>
> > I'm still inclined to not release rel2 if we can't bring the
> > XSL implementations together; deprecation is a better option. If we can
> > bring them together, then great; if not, I don't really want
> > to be working on the same classes as you. Seems wasteful. I'd rather
> > have two guys working on one lib then two guys working on two. :(
> >
> > This reminds me of when Jakarta released ORO. There was not a lot of info
> > on what the advantages/disadvantages were between ORO and Regexp, and it
> > just left me cold as a user. I'd like to avoid that here if possible,
> > even if that means shelving a new XSL release.
>
> I'm now in total agreement. Lets not worry about the dom4j and DOM
> dependencies right now. There will be ways to minimise those later.
>
> Lets share & combine our efforts. Its just a question now of is it one tag
> library or one code base with a 2 TLDs, a 'just XSLT' and a 'XSLT + XPath'
>
> James
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Morgan
From: "Morgan Delagrange" <mo...@apache.org>
> > 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.
>
> All that sounds like useful functionality for the basic XSL tags as
> well. That's why I want to avoid two sets of classes. (XTags does this
> but not that, XSL does that but not this.)
If the dependence on dom4j and DOM is not an issue right now, I'd love us to
combine our efforts into a single library.
So lets do it. If the dependency ever becomes a real issue we can revisit
this decision. I'm sure there are ways to at least minimise the dependency.
> > So the <xtags:style> tag has both compile time and runtime dependencies
on
> > both the DOM interfaces and the dom4j interfaces.
>
> I don't think I have a problem with adding that to XSL, if that's what it
> takes to bring the implementations together.
Cool.
>
> > 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.
>
> Sure, that's what I think is best.
So either we have a single taglib or we share the same code over 2 TLDs,
'just XSL' or 'XSL + XPath'.
Which would you prefer? For simplicity and consolidation (just 1 web page, 1
set of documentation, 1 TLD and so on) I'd prefer one library though I could
be persuaded either way.
> I'd like to peek at it and see if it's possible to remove non-JAXP
> dependencies at runtime (don't care about compile-time); other project
> have managed similar tricks. But if it's prohibitive, I'm willing to
> increase the XSL dependencies in order to remove the duplication of
> effort.
I think its prohibitive right now but something we could address in the
future.
> I'm still inclined to not release rel2 if we can't bring the
> XSL implementations together; deprecation is a better option. If we can
> bring them together, then great; if not, I don't really want
> to be working on the same classes as you. Seems wasteful. I'd rather
> have two guys working on one lib then two guys working on two. :(
>
> This reminds me of when Jakarta released ORO. There was not a lot of info
> on what the advantages/disadvantages were between ORO and Regexp, and it
> just left me cold as a user. I'd like to avoid that here if possible,
> even if that means shelving a new XSL release.
I'm now in total agreement. Lets not worry about the dom4j and DOM
dependencies right now. There will be ways to minimise those later.
Lets share & combine our efforts. Its just a question now of is it one tag
library or one code base with a 2 TLDs, a 'just XSLT' and a 'XSLT + XPath'
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
On Tue, 19 Jun 2001, James Strachan wrote:
> From: "Morgan Delagrange" <mo...@apache.org>
> > 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.
All that sounds like useful functionality for the basic XSL tags as
well. That's why I want to avoid two sets of classes. (XTags does this
but not that, XSL does that but not this.)
> 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.
I don't think I have a problem with adding that to XSL, if that's what it
takes to bring the implementations together.
> 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.
Sure, that's what I think is best.
> 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>).
I'd like to peek at it and see if it's possible to remove non-JAXP
dependencies at runtime (don't care about compile-time); other project
have managed similar tricks. But if it's prohibitive, I'm willing to
increase the XSL dependencies in order to remove the duplication of
effort.
> >
> > >
> > > > 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?
>
I'm still inclined to not release rel2 if we can't bring the
XSL implementations together; deprecation is a better option. If we can
bring them together, then great; if not, I don't really want
to be working on the same classes as you. Seems wasteful. I'd rather
have two guys working on one lib then two guys working on two. :(
This reminds me of when Jakarta released ORO. There was not a lot of info
on what the advantages/disadvantages were between ORO and Regexp, and it
just left me cold as a user. I'd like to avoid that here if possible,
even if that means shelving a new XSL release.
- Morgan
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "Morgan Delagrange" <mo...@apache.org>
> 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
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
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.
>
> > 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.
>
> > 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.
>
>
> Agreed, lets keep XSL for those who just want to do XSLT with minimal
> dependencies (just JAXP).
>
> > I suspect that the XSLT interface would
> > be stronger and have more contributors as a result, and I bet so would the
> > XPATH support.
>
> 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.
>
> James
>
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.
- Morgan
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by James Strachan <ja...@yahoo.co.uk>.
> 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).
> 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).
> 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.
Agreed, lets keep XSL for those who just want to do XSLT with minimal
dependencies (just JAXP).
> I suspect that the XSLT interface would
> be stronger and have more contributors as a result, and I bet so would the
> XPATH support.
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.
James
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
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" <mo...@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
>
>
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by James Strachan <ja...@yahoo.co.uk>.
Hi Morgan
From: "Morgan Delagrange" <mo...@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
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
Thanks for the help. I thought I did a find and replace on the whole
tree, but I must have just done the source tree.
On Tue, 3 Jul 2001, Glenn Nielsen wrote:
> Thanks for changing jdbc to dbtags. I had to fix a couple things to get
> the build to work. But its all done now.
>
> Glenn
>
> Morgan Delagrange wrote:
> >
> > Wow, thanks! I'll get on it.
> >
> > On Sat, 30 Jun 2001, Glenn Nielsen wrote:
> >
> > > Morgan Delagrange wrote:
> > > >
> > > > On Wed, 13 Jun 2001, Glenn Nielsen wrote:
> > > >
> > > > > re DBTags:
> > > > >
> > > > > It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
> > > > > were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
> > > > > using the "jdbc" directory inside DBTags changed to "dbtags". You should just
> > > > > be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
> > > >
> > > > Does that work? I didn't want to move the directories, because I wanted
> > > > to maintain the CVS history. Although I suppose that since DBTags is
> > > > still pre-release, it doesn't really matter that much.
> > > >
> > > > OK, as long as it is safe to rename CVS directories, I'll do so. I'm
> > > > assuming that you've renamed directories before and that it doesn't cause
> > > > any problems with the CVS metadata.
> > > >
> > >
> > > The following directory name changes should be made.
> > >
> > > jakarta-taglibs/jdbc/src/org/apache/taglibs/jdbc
> > > -> jakarta-taglibs/jdbc/src/org/apache/taglibs/dbtags
> > >
> > > jakarta-taglibs/jdbc -> jakarta-taglibs/dbtags
> > >
> > > The following link shows how to move a directory within the repository.
> > >
> > > http://cvsbook.red-bean.com/cvsbook.html#I_need_to_move_files_around_without_losing_revision_history
> > >
> > > Then update jakarta-taglibs/build.xml so that the target is dbtags instead of jdbc.
> > > And update the package declarations in the java source files in
> > > jakarta-taglibs/dbtags/src/org/apache/taglibs/dbtags/*
> > > so that they use package org.apache.taglibs.dbtags.
> > >
> > > Thanks,
> > >
> > > Glenn
> > >
> > > ----------------------------------------------------------------------
> > > Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> > > MOREnet System Programming | * if iz ina coment. |
> > > Missouri Research and Education Network | */ |
> > > ----------------------------------------------------------------------
> > >
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Thanks for changing jdbc to dbtags. I had to fix a couple things to get
the build to work. But its all done now.
Glenn
Morgan Delagrange wrote:
>
> Wow, thanks! I'll get on it.
>
> On Sat, 30 Jun 2001, Glenn Nielsen wrote:
>
> > Morgan Delagrange wrote:
> > >
> > > On Wed, 13 Jun 2001, Glenn Nielsen wrote:
> > >
> > > > re DBTags:
> > > >
> > > > It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
> > > > were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
> > > > using the "jdbc" directory inside DBTags changed to "dbtags". You should just
> > > > be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
> > >
> > > Does that work? I didn't want to move the directories, because I wanted
> > > to maintain the CVS history. Although I suppose that since DBTags is
> > > still pre-release, it doesn't really matter that much.
> > >
> > > OK, as long as it is safe to rename CVS directories, I'll do so. I'm
> > > assuming that you've renamed directories before and that it doesn't cause
> > > any problems with the CVS metadata.
> > >
> >
> > The following directory name changes should be made.
> >
> > jakarta-taglibs/jdbc/src/org/apache/taglibs/jdbc
> > -> jakarta-taglibs/jdbc/src/org/apache/taglibs/dbtags
> >
> > jakarta-taglibs/jdbc -> jakarta-taglibs/dbtags
> >
> > The following link shows how to move a directory within the repository.
> >
> > http://cvsbook.red-bean.com/cvsbook.html#I_need_to_move_files_around_without_losing_revision_history
> >
> > Then update jakarta-taglibs/build.xml so that the target is dbtags instead of jdbc.
> > And update the package declarations in the java source files in
> > jakarta-taglibs/dbtags/src/org/apache/taglibs/dbtags/*
> > so that they use package org.apache.taglibs.dbtags.
> >
> > Thanks,
> >
> > Glenn
> >
> > ----------------------------------------------------------------------
> > Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> > MOREnet System Programming | * if iz ina coment. |
> > Missouri Research and Education Network | */ |
> > ----------------------------------------------------------------------
> >
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
Wow, thanks! I'll get on it.
On Sat, 30 Jun 2001, Glenn Nielsen wrote:
> Morgan Delagrange wrote:
> >
> > On Wed, 13 Jun 2001, Glenn Nielsen wrote:
> >
> > > re DBTags:
> > >
> > > It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
> > > were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
> > > using the "jdbc" directory inside DBTags changed to "dbtags". You should just
> > > be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
> >
> > Does that work? I didn't want to move the directories, because I wanted
> > to maintain the CVS history. Although I suppose that since DBTags is
> > still pre-release, it doesn't really matter that much.
> >
> > OK, as long as it is safe to rename CVS directories, I'll do so. I'm
> > assuming that you've renamed directories before and that it doesn't cause
> > any problems with the CVS metadata.
> >
>
> The following directory name changes should be made.
>
> jakarta-taglibs/jdbc/src/org/apache/taglibs/jdbc
> -> jakarta-taglibs/jdbc/src/org/apache/taglibs/dbtags
>
> jakarta-taglibs/jdbc -> jakarta-taglibs/dbtags
>
> The following link shows how to move a directory within the repository.
>
> http://cvsbook.red-bean.com/cvsbook.html#I_need_to_move_files_around_without_losing_revision_history
>
> Then update jakarta-taglibs/build.xml so that the target is dbtags instead of jdbc.
> And update the package declarations in the java source files in
> jakarta-taglibs/dbtags/src/org/apache/taglibs/dbtags/*
> so that they use package org.apache.taglibs.dbtags.
>
> Thanks,
>
> Glenn
>
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Morgan Delagrange wrote:
>
> On Wed, 13 Jun 2001, Glenn Nielsen wrote:
>
> > re DBTags:
> >
> > It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
> > were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
> > using the "jdbc" directory inside DBTags changed to "dbtags". You should just
> > be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
>
> Does that work? I didn't want to move the directories, because I wanted
> to maintain the CVS history. Although I suppose that since DBTags is
> still pre-release, it doesn't really matter that much.
>
> OK, as long as it is safe to rename CVS directories, I'll do so. I'm
> assuming that you've renamed directories before and that it doesn't cause
> any problems with the CVS metadata.
>
The following directory name changes should be made.
jakarta-taglibs/jdbc/src/org/apache/taglibs/jdbc
-> jakarta-taglibs/jdbc/src/org/apache/taglibs/dbtags
jakarta-taglibs/jdbc -> jakarta-taglibs/dbtags
The following link shows how to move a directory within the repository.
http://cvsbook.red-bean.com/cvsbook.html#I_need_to_move_files_around_without_losing_revision_history
Then update jakarta-taglibs/build.xml so that the target is dbtags instead of jdbc.
And update the package declarations in the java source files in
jakarta-taglibs/dbtags/src/org/apache/taglibs/dbtags/*
so that they use package org.apache.taglibs.dbtags.
Thanks,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
On Wed, 13 Jun 2001, Glenn Nielsen wrote:
> Morgan,
>
> As you probably know, I am doing alot of work on the jakarta-taglibs
> build, nightly, documentation, release processes. I anticipate being
> done early next week. I will also look into signing of distributions
> and jar files. If we are going to start doing official releases, we
> might as well do it right.
I agree.
> re DBTags:
>
> It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
> were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
> using the "jdbc" directory inside DBTags changed to "dbtags". You should just
> be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
Does that work? I didn't want to move the directories, because I wanted
to maintain the CVS history. Although I suppose that since DBTags is
still pre-release, it doesn't really matter that much.
OK, as long as it is safe to rename CVS directories, I'll do so. I'm
assuming that you've renamed directories before and that it doesn't cause
any problems with the CVS metadata.
> Thanks,
>
> Glenn
>
> Morgan Delagrange wrote:
> >
> > Hi all,
> >
> > I just wanted to give y'all a heads-up that I'm going to review some
> > patches and such to DBTags and XSL that have been contributed over the
> > past couple of months. If you don't see your patches being addressed over
> > the next few weeks, drop a note to the list.
> >
> > I also want to resume discussions on binary releases. This is for
> > perfectly selfish reasons, since I can't really merge in the release 2 XSL
> > tag library until release 1 has been committed to posterity.
> >
> > Finally, if you're already a committer and would like to contribute, feel
> > free! 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.
> >
> > - Morgan
>
> --
> ----------------------------------------------------------------------
> Glenn Nielsen glenn@more.net | /* Spelin donut madder |
> MOREnet System Programming | * if iz ina coment. |
> Missouri Research and Education Network | */ |
> ----------------------------------------------------------------------
>
Re: Work on DBTags and XSL, release 2, and etcetera
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
Morgan,
As you probably know, I am doing alot of work on the jakarta-taglibs
build, nightly, documentation, release processes. I anticipate being
done early next week. I will also look into signing of distributions
and jar files. If we are going to start doing official releases, we
might as well do it right.
re DBTags:
It would make the nightly build and releases easier if /home/cvs/jakarta-taglibs/jdbc
were renamed to /home/cvs/jakarta-taglibs/dbtags on daedalus, and any references to
using the "jdbc" directory inside DBTags changed to "dbtags". You should just
be able to do an "mv jdbc dbtags" in /home/cvs/jakarta-taglibs on daedalus.
Thanks,
Glenn
Morgan Delagrange wrote:
>
> Hi all,
>
> I just wanted to give y'all a heads-up that I'm going to review some
> patches and such to DBTags and XSL that have been contributed over the
> past couple of months. If you don't see your patches being addressed over
> the next few weeks, drop a note to the list.
>
> I also want to resume discussions on binary releases. This is for
> perfectly selfish reasons, since I can't really merge in the release 2 XSL
> tag library until release 1 has been committed to posterity.
>
> Finally, if you're already a committer and would like to contribute, feel
> free! 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.
>
> - Morgan
--
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
RE: Work on DBTags and XSL, release 2, and etcetera
Posted by Morgan Delagrange <mo...@apache.org>.
Stay tuned. :) I'd like to talk a little more about integrating XTags
and XSL before we commit too much time to the new XSL branch.
On Thu, 14 Jun 2001, Nick Sharples wrote:
> I have a patch (and probably so do you ;) for XSL to allow jaxp 1.1. I'm
> wary of posting it in case you already have too many of these. Let me know
> if it's wanted.
>
> Cheers,
> Nick
>
>
RE: Work on DBTags and XSL, release 2, and etcetera
Posted by Nick Sharples <ni...@eejits.net>.
I have a patch (and probably so do you ;) for XSL to allow jaxp 1.1. I'm
wary of posting it in case you already have too many of these. Let me know
if it's wanted.
Cheers,
Nick