You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by bu...@apache.org on 2002/09/02 18:34:35 UTC
DO NOT REPLY [Bug 12235] New: -
[PATCH] XPathTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12235>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12235
[PATCH] XPathTransformer
Summary: [PATCH] XPathTransformer
Product: Cocoon 2
Version: Current CVS
Platform: Other
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: sitemap components
AssignedTo: cocoon-dev@xml.apache.org
ReportedBy: jefft@apache.org
Hi,
Attached is a transformer which lets one 'prune' an XML source, by specifying
'include' and 'exclude' XPath expressions. Ie, nodes matched by the 'include'
expression are let through, and those matched by 'exclude' are filtered out. My
use-case is that I have a single large XML file containing a user manual, and
I'd like to render chapters of it separately. This can be done as follows:
<map:match pattern="manual/*">
<map:generate src="manual.xml"/>
<map:transform type="xpath">
<map:parameter name="include" value="/manual/s1[@title='{1}']"/>
</map:transform>
<map:transform src="chapter2html.xsl"/>
<map:serialize/>
</map:match>
While this sort of filtering can be done with XSLT, it can't be done
dynamically, based on an input parameter, because XSLT template patterns must
be known at 'compile' time, not runtime, much like the sitemap's matchers. See
cocoon-users discussion:
http://marc.theaimsgroup.com/?t=103069471700001&r=1&w=2
As an example use, consider the changes.xml file, of the format:
<changes title="History of Changes">
<devs .. />
<release version="2.1-dev">
<action dev=".." update="..">
..
</action>
..
</release>
..
</changes>
With the attached addition to sitemap.xmap, one could have the url:
http://localhost:8080/cocoon/documents/changes/release(2.1-dev)
lists only changes in the 2.1-dev branch, by applying the transformation:
<map:match pattern="changes/release(*)">
<map:generate src="xdocs/changes.xml"/>
<map:transform type="xpath">
<map:parameter name="exclude" value="/changes/release[@version != '{1}']"/>
</map:transform>
..
More generally, the pattern:
<map:match pattern="changes/*(*)">
<map:generate src="xdocs/changes.xml"/>
<map:transform type="xpath">
<map:parameter name="exclude" value="//action[@{1} != '{2}']"/>
</map:transform>
...
Which allows one to, for instance, list all changes made by developer 'NKB' as
follows:
http://localhost:8080/cocoon/documents/changes/dev(NKB)
or list all fixes made in the different versions:
http://localhost:8080/cocoon/documents/changes/type(fix)
Which is kinda neat :)
The transformer builds a DOM, which is unfortunate but necessary for XPath. A
more SAX-friendly approach would be to use stx (http://stx.gingerall.cz/stx/).
XPathTransformer implements Cacheable to somewhat compensate for DOM yuckiness.
Feedback welcome.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Jeff Turner wrote:
> The problem is conceptual, that document() breaks SoC, as described at
> http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully
> things like XPathTransformer will remove the need for document()
> altogether.
I'd be bothered more with the problem that document()'ed
stuff is not revalidated for caching together with the main
source...
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Nicola Ken Barozzi wrote:
> Why use Cocoon at all?
Pipelined XML processing is great. Also, Cocoon is really
great for mapping URLs to content. Including dynamic
content (with some work flow support it would be even
better).
As for Cocoon aggregation vs. document(): aggregation
is good if the structure of the aggregated stuff is
relatively static. It's somewhat clumsy if parts of the
URLs come from the XML source, and in particular if the
number of aggregated parts varies. In these cases you
need a three stage pipeline: transformation to xincludes,
doing the actual include, then the final transformation.
This split of the whole process into two transformations
can be an advantage, but in most cases I found it more
of a problem during maintenance.
> You need the right tool for the right job.
Indeed.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: Tuesday, September 03, 2002 8:15 AM
> Robert Koberg wrote:
>
> >>The problem is conceptual, that document() breaks SoC, as described at
> >>http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully
> >>things like XPathTransformer will remove the need for document()
> >>altogether.
> >
> >
> > Yea, I have heard the argument.
> >
> > I just don't understand why you can't use XSL to separate out some these
> > concerns.
>
> Don't use Cocoon then, use XSLT.
> You can use XSLT extensions instead of the DB Generator, make your own
> extensions instead of XSP taglibs or use document() for aggregation.
>
> Why use Cocoon at all?
For three resons:
1. It does some things really well
2. Some things should not be done in XSL
3. I know I will have clients who will want to use it
>
> > Hmmm... one line of XSLT v. (at least) one class
> >
> > Perhaps (the general) you could create a 'business-logic' directory and put
> > these 'worker' XSLs in it to avoid the cognitive dissonance.
> >
> > XSL has many uses, why psuedo-cripple it?
>
> You need the right tool for the right job.
very true
>
> This transformer, if done well, can be faster, more efficient than xslt,
> which is more general-purpose.
I guess I would like to see the numbers on this for the entire transformation.
>
> Anyway, it isn't compulsory, you can use whatever you prefer.
Yes, I know. That is why I originally responded with a 'For the record.' But,
for some reason, I bristle when SoC is invoked in a dogmatic way.
I wish cocoon's best practices would include using the document function (and
xsl:include/import) where appropriate.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Robert Koberg wrote:
>>The problem is conceptual, that document() breaks SoC, as described at
>>http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully
>>things like XPathTransformer will remove the need for document()
>>altogether.
>
>
> Yea, I have heard the argument.
>
> I just don't understand why you can't use XSL to separate out some these
> concerns.
Don't use Cocoon then, use XSLT.
You can use XSLT extensions instead of the DB Generator, make your own
extensions instead of XSP taglibs or use document() for aggregation.
Why use Cocoon at all?
> Hmmm... one line of XSLT v. (at least) one class
>
> Perhaps (the general) you could create a 'business-logic' directory and put
> these 'worker' XSLs in it to avoid the cognitive dissonance.
>
> XSL has many uses, why psuedo-cripple it?
You need the right tool for the right job.
This transformer, if done well, can be faster, more efficient than xslt,
which is more general-purpose.
Anyway, it isn't compulsory, you can use whatever you prefer.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: Jeff Turner [mailto:jefft@apache.org]
> Sent: Monday, September 02, 2002 6:35 PM
> > On Mon, Sep 02, 2002 at 05:11:28PM -0700, Robert Koberg wrote:
> > Hi,
> >
> > For the record, I would say it is very easy in XSL. This was from
> the original
> > bug report:
> >
> > <map:parameter name="include" value="/manual/s1[@title='{1}']"/>
> >
> > To get this with xsl you could simply:
> >
> > <xsl:apply-templates
> > select="document($book_param)/manual/s1[@title=$section_title_param]"/>
>
> Hadn't thought of that. Cunning :)
>
> > Now, the problem might be that the book is too large... (probably
> not for Saxon,
> > though)
>
> The problem is conceptual, that document() breaks SoC, as described at
> http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully
> things like XPathTransformer will remove the need for document()
> altogether.
Yea, I have heard the argument.
I just don't understand why you can't use XSL to separate out some these
concerns.
Hmmm... one line of XSLT v. (at least) one class
Perhaps (the general) you could create a 'business-logic' directory and put
these 'worker' XSLs in it to avoid the cognitive dissonance.
XSL has many uses, why psuedo-cripple it?
-Rob
>
> --Jeff
>
>
> > best,
> > -Rob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 02, 2002 at 05:11:28PM -0700, Robert Koberg wrote:
> Hi,
>
> For the record, I would say it is very easy in XSL. This was from the original
> bug report:
>
> <map:parameter name="include" value="/manual/s1[@title='{1}']"/>
>
> To get this with xsl you could simply:
>
> <xsl:apply-templates
> select="document($book_param)/manual/s1[@title=$section_title_param]"/>
Hadn't thought of that. Cunning :)
> Now, the problem might be that the book is too large... (probably not for Saxon,
> though)
The problem is conceptual, that document() breaks SoC, as described at
http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully
things like XPathTransformer will remove the need for document()
altogether.
--Jeff
> best,
> -Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
For the record, I would say it is very easy in XSL. This was from the original
bug report:
<map:parameter name="include" value="/manual/s1[@title='{1}']"/>
To get this with xsl you could simply:
<xsl:apply-templates
select="document($book_param)/manual/s1[@title=$section_title_param]"/>
Now, the problem might be that the book is too large... (probably not for Saxon,
though)
best,
-Rob
> -----Original Message-----
> From: Jeff Turner [mailto:jefft@apache.org]
> Sent: Monday, September 02, 2002 4:57 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
>
>
> On Mon, Sep 02, 2002 at 07:30:21PM +0200, Joerg Heinicke wrote:
> > > While this sort of filtering can be done with XSLT, it can't be done
> > > dynamically, based on an input parameter, because XSLT template patterns
> > must
> > > be known at 'compile' time, not runtime, much like the sitemap's
> > matchers. See
> > > cocoon-users discussion:
> > > http://marc.theaimsgroup.com/?t=103069471700001&r=1&w=2
> >
> > Hmm, I think it can be done with XSLT, but you have to write XSLT by XSLT
> > or a XML file with some xinclude statements and use xinclude transformer.
>
> Given that XSLT is Turing complete [1], one can do *anything* with a
> dynamically generated XSLT ;) The issue is ease of use and efficiency,
> for which I think XPathTransformer easily beats dynamically generated
> XSLT or xinclude-including XSP pages.
>
>
> --Jeff
>
> [1] http://www.unidex.com/turing/utm.htm
>
> >
> > Joerg
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Jeff Turner <je...@apache.org>.
On Mon, Sep 02, 2002 at 07:30:21PM +0200, Joerg Heinicke wrote:
> > While this sort of filtering can be done with XSLT, it can't be done
> > dynamically, based on an input parameter, because XSLT template patterns
> must
> > be known at 'compile' time, not runtime, much like the sitemap's
> matchers. See
> > cocoon-users discussion:
> > http://marc.theaimsgroup.com/?t=103069471700001&r=1&w=2
>
> Hmm, I think it can be done with XSLT, but you have to write XSLT by XSLT
> or a XML file with some xinclude statements and use xinclude transformer.
Given that XSLT is Turing complete [1], one can do *anything* with a
dynamically generated XSLT ;) The issue is ease of use and efficiency,
for which I think XPathTransformer easily beats dynamically generated
XSLT or xinclude-including XSP pages.
--Jeff
[1] http://www.unidex.com/turing/utm.htm
>
> Joerg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Posted by Joerg Heinicke <jo...@gmx.de>.
> While this sort of filtering can be done with XSLT, it can't be done
> dynamically, based on an input parameter, because XSLT template patterns must
> be known at 'compile' time, not runtime, much like the sitemap's
matchers. See
> cocoon-users discussion:
> http://marc.theaimsgroup.com/?t=103069471700001&r=1&w=2
Hmm, I think it can be done with XSLT, but you have to write XSLT by XSLT or
a XML file with some xinclude statements and use xinclude transformer.
I don't know what's the better approach for your problem.
Regards,
Joerg
--
System Development
VIRBUS AG
Fon +49(0)341-979-7419
Fax +49(0)341-979-7409
joerg.heinicke@virbus.de
www.virbus.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org