You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by David <co...@max-imp.com> on 2005/10/02 04:25:11 UTC
multiple xpaths
I am writing a cocoon transformer and need to know when any of multiple
xpaths match. I'm sure there must be a be a more efficient way then
converting it to a DOM document and then running each xpath to get the
nodelist of each.
What is the best way to do this?
Thanks,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches
Posted by Sandor Spruit <sa...@cs.uu.nl>.
On 4 Oct 2005, at 13:19, Geert Josten wrote:
>> What i meant was:
>> <template match="*">
>> <xsl:apply-templates select="xalan:evaluate($xpath)" mode="my-
>> xpath-mode"/>
>> </template>
>> <template match="*" mode="my-xpath-mode">
>> <choose>
>> <!-- Or any other check -->
>> <when test="contains($xpath,'sth')">
>> Do sth with nodes when the xpath contains "sth"
>> </when>
>> <otherwise>
>> Do sth else
>> </otherwise>
>> </choose>
>> </template>
>>
>
> Ah, just one mode string. Ever used this approach? With the
> evaluate in it I mean?
>
>
>> And the above example would match the xpath expression contained in
>> $xpath doesn't it? (That was the Goal i thought.)
>>
>
> Though I'm not the problem owner (so don't ask me about the
> goal ;), i think this approach with apply-templates is useful in
> only limited situations. The original posted tried to test for
> certain xpaths. That can be done with the apply-templates, somehow,
> I guess. But the one that suggested to generate an XSL had a
> different use case, in which most is copied and the xpath matching
> elements were only marked. In that case apply-templates is not that
> useful...
>
Exactly! Spot-on, said the original problem owner
still struggling to get things working as intended.
Damned, and I left this issue casually lying around
to be resolved later. If only I'd known... :(
Sandor
Sandor Spruit
sandor@cs.uu.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches
Posted by Geert Josten <Ge...@daidalos.nl>.
> What i meant was:
>
> <template match="*">
> <xsl:apply-templates select="xalan:evaluate($xpath)" mode="my-xpath-mode"/>
> </template>
>
> <template match="*" mode="my-xpath-mode">
> <choose>
> <!-- Or any other check -->
> <when test="contains($xpath,'sth')">
> Do sth with nodes when the xpath contains "sth"
> </when>
> <otherwise>
> Do sth else
> </otherwise>
> </choose>
> </template>
Ah, just one mode string. Ever used this approach? With the evaluate in it I mean?
> And the above example would match the xpath expression contained in
> $xpath doesn't it? (That was the Goal i thought.)
Though I'm not the problem owner (so don't ask me about the goal ;), i think this approach with
apply-templates is useful in only limited situations. The original posted tried to test for certain
xpaths. That can be done with the apply-templates, somehow, I guess. But the one that suggested to
generate an XSL had a different use case, in which most is copied and the xpath matching elements
were only marked. In that case apply-templates is not that useful...
:-P
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches
Posted by Christoph Hermann <ch...@guschtel.de>.
Geert Josten schrieb:
Hello,
>>> No, this gets worse, actually. You cannot use parameters or expressions
>>> at all in a mode attribute. :-(
>>>
>>> And by replacing the expression by a string, you remove the dynamic
>>> element again.. :-P
>> Why? I mean the "xpath string" is still evaluated for a different xpath.
>> Or do you need every xpath to be processed differently?
>> If then make the difference by looking at your variable (which is
>> static).
> You can use a literal xpath string in a mode attribute, but you will
> have to guess which xpath expressions might occur if you want the XSL to
> be static.
>
> Next to this, you cannot use {..} inside a mode attribute, not at
> xsl:apply-templates, nor at xsl:template.
What i meant was:
<template match="*">
<xsl:apply-templates select="xalan:evaluate($xpath)" mode="my-xpath-mode"/>
</template>
<template match="*" mode="my-xpath-mode">
<choose>
<!-- Or any other check -->
<when test="contains($xpath,'sth')">
Do sth with nodes when the xpath contains "sth"
</when>
<otherwise>
Do sth else
</otherwise>
</choose>
</template>
> You could use your method in a generated XSL, though, but then are you
> making things more difficult than necessary.. :-P
And the above example would match the xpath expression contained in
$xpath doesn't it? (That was the Goal i thought.)
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches
Posted by Geert Josten <Ge...@daidalos.nl>.
>>No, this gets worse, actually. You cannot use parameters or expressions
>>at all in a mode attribute. :-(
>>
>>And by replacing the expression by a string, you remove the dynamic
>>element again.. :-P
>
>
> Why? I mean the "xpath string" is still evaluated for a different xpath.
> Or do you need every xpath to be processed differently?
> If then make the difference by looking at your variable (which is static).
>
> Or did i get sth wrong?
> Christoph
I'm not sure I understand what you are trying to say, so I'll just explain the problems a bit further.
You can use a literal xpath string in a mode attribute, but you will have to guess which xpath
expressions might occur if you want the XSL to be static.
Next to this, you cannot use {..} inside a mode attribute, not at xsl:apply-templates, nor at
xsl:template.
You could use your method in a generated XSL, though, but then are you making things more difficult
than necessary.. :-P
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches
Posted by Christoph Hermann <ch...@guschtel.de>.
Geert Josten schrieb:
Hello,
>> [named/mode templates]
>> <xsl:template match="*">
>> <xsl:apply-templates select="xalan:evaluate($parameter_xpath)"
>> mode="{$parameter_xpath}" />
>> </...>
>>
>> and then a
>> <xsl:template match="*" mode="{$parameter_xpath}" ...>
>>
>> (untested)
>> I don't know if this works, maybe substitute the
>> mode="{$parameter_xpath}" with mode="somestring".
> No, this gets worse, actually. You cannot use parameters or expressions
> at all in a mode attribute. :-(
>
> And by replacing the expression by a string, you remove the dynamic
> element again.. :-P
Why? I mean the "xpath string" is still evaluated for a different xpath.
Or do you need every xpath to be processed differently?
If then make the difference by looking at your variable (which is static).
Or did i get sth wrong?
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: dynamic template matches (was: multiple xpaths)
Posted by Geert Josten <Ge...@daidalos.nl>.
(changed the subject line)
> An other Idea i came up with yesterday was the use of names for your
> template.
> So if you do a
> <xsl:template match="*">
> <xsl:apply-templates select="xalan:evaluate($parameter_xpath)"
> mode="{$parameter_xpath}" />
> </...>
>
> and then a
> <xsl:template match="*" mode="{$parameter_xpath}" ...>
>
> (untested)
> I don't know if this works, maybe substitute the
> mode="{$parameter_xpath}" with mode="somestring".
>
> Christoph
No, this gets worse, actually. You cannot use parameters or expressions at all in a mode attribute. :-(
And by replacing the expression by a string, you remove the dynamic element again.. :-P
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Christoph Hermann <ch...@guschtel.de>.
Sandor Spruit schrieb:
Hello,
>>> ... select="xalan:evaluate($parameter_xpath)"
>> I was hoping for a reply like this - even though a dynamic stylesheet
>> seemed to be a smart move :) I'll give it a try this afternoon.
> The use of an extension function *would* but much easier - if it worked,
> but it doesn't. The extension function does not seem to be allowed as the
> pattern in <xsl:template match="pattern">. Errors all over the place.
>
> Was does work is the use of the extension in calls to xsl:apply-templates,
> but that is not what I want. It will help iff you want to apply a
> template to
> one specific XPath. What I need is to copy the entire XML tree using a
> regular xsl:copy, with some extra highlighting tags inserted for the XPath.
An other Idea i came up with yesterday was the use of names for your
template.
So if you do a
<xsl:template match="*">
<xsl:apply-templates select="xalan:evaluate($parameter_xpath)"
mode="{$parameter_xpath}" />
</...>
and then a
<xsl:template match="*" mode="{$parameter_xpath}" ...>
(untested)
I don't know if this works, maybe substitute the
mode="{$parameter_xpath}" with mode="somestring".
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Sandor Spruit <sa...@cs.uu.nl>.
Geert Josten wrote:
> > Was does work is the use of the extension in calls to
> > xsl:apply-templates, but that is not what I want. It will help iff
> > you want to apply a template to one specific XPath. What I need is
> > to copy the entire XML tree using a regular xsl:copy, with some
> > extra highlighting tags inserted for the XPath.
>
> You might want to take a look at the HighlightingTransformer that has
> been donated only a week or two ago. Look for messages with that name
> in the cocoon-dev mailinglist.
Duh. Somebody beat me to it! :(
> Though, I think it marks keywords, not element matching a specific
> xpath...
That might be a useful extension though ... :)
> By the way, I think you approach of generating a XSL to achieve the
> highlighting is not bad at all, quite powerful even. I have been
> using the approach on many fields allready. Mostly for template
> mechanisms (when jxgenerator wasn't yet around).
Thanks - I needed that. Deadline approaching ;)
> In your case performance might be an issue though. When the Xpaths
> vary a lot, a new XSL has to be generated, compiled and cached each
> time. :-(
Well, performance has been pretty good so far. In fact, excellent. Maybe
it won't be so bad....
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
> Was does work is the use of the extension in calls to xsl:apply-templates,
> but that is not what I want. It will help iff you want to apply a
> template to
> one specific XPath. What I need is to copy the entire XML tree using a
> regular xsl:copy, with some extra highlighting tags inserted for the XPath.
You might want to take a look at the HighlightingTransformer that has been donated only a week or
two ago. Look for messages with that name in the cocoon-dev mailinglist.
Though, I think it marks keywords, not element matching a specific xpath...
By the way, I think you approach of generating a XSL to achieve the highlighting is not bad at all,
quite powerful even. I have been using the approach on many fields allready. Mostly for template
mechanisms (when jxgenerator wasn't yet around).
In your case performance might be an issue though. When the Xpaths vary a lot, a new XSL has to be
generated, compiled and cached each time. :-(
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Sandor Spruit <sa...@cs.uu.nl>.
Sandor Spruit wrote:
> Christoph Hermann wrote:
>
>> Am Sonntag, 2. Oktober 2005 21:04 schrieb Sandor Spruit:
>>
[description of dynamic stylesheet idea snipped]
>> Wouldn't it be _much_ easier to use xalan extensions for this purpose?
>>
>> <xsl:stylesheet version="1.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> xmlns:xalan="http://xml.apache.org/xalan">
>> <xsl:param name="parameter_xpath"/>
>> ...
>> ... select="xalan:evaluate($parameter_xpath)"
>>
>>
>
> I was hoping for a reply like this - even though a dynamic stylesheet
> seemed to be a smart move :) I'll give it a try this afternoon.
The use of an extension function *would* but much easier - if it worked,
but it doesn't. The extension function does not seem to be allowed as the
pattern in <xsl:template match="pattern">. Errors all over the place.
Was does work is the use of the extension in calls to xsl:apply-templates,
but that is not what I want. It will help iff you want to apply a
template to
one specific XPath. What I need is to copy the entire XML tree using a
regular xsl:copy, with some extra highlighting tags inserted for the XPath.
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Sandor Spruit <sa...@cs.uu.nl>.
Christoph Hermann wrote:
>Am Sonntag, 2. Oktober 2005 21:04 schrieb Sandor Spruit:
>
>Hello,
>
>
>>Don't know about the best way, but I had a similar problem recently:
>>I wanted to apply a transformation to specific elements, pointed to by
>>an XPath expression. The basic problem was that XSLT will not allow
>>a variable where it expects an XPath, i.e. xsl:template match="$xpath".
>>
>>One of our students came up with this idea: create the *stylesheet* in a
>>separate (internal) Cocoon pipeline. Create a placeholder in your XSLT
>>where you'd normally insert an XPath expression, i.e. 'please-replace-me',
>>and define a variable for this stylesheet. Write a simple stylesheet to
>>copy the "stylesheet" template, but replacing the placeholder with your
>>XPath.
>>
>>Use the result of this pipeline ('a dynamic stylesheet') from your regular
>>Cocoon pipeline using the cocoon:/ pseudo-protocol.
>>
>>
>
>Wouldn't it be _much_ easier to use xalan extensions for this purpose?
>
><xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:xalan="http://xml.apache.org/xalan">
> <xsl:param name="parameter_xpath"/>
>...
>... select="xalan:evaluate($parameter_xpath)"
>
>
I was hoping for a reply like this - even though a dynamic stylesheet
seemed to be a smart move :) I'll give it a try this afternoon.
cheers,
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Christoph Hermann <ch...@guschtel.de>.
Am Sonntag, 2. Oktober 2005 21:04 schrieb Sandor Spruit:
Hello,
> Don't know about the best way, but I had a similar problem recently:
> I wanted to apply a transformation to specific elements, pointed to by
> an XPath expression. The basic problem was that XSLT will not allow
> a variable where it expects an XPath, i.e. xsl:template match="$xpath".
>
> One of our students came up with this idea: create the *stylesheet* in a
> separate (internal) Cocoon pipeline. Create a placeholder in your XSLT
> where you'd normally insert an XPath expression, i.e. 'please-replace-me',
> and define a variable for this stylesheet. Write a simple stylesheet to
> copy the "stylesheet" template, but replacing the placeholder with your
> XPath.
>
> Use the result of this pipeline ('a dynamic stylesheet') from your regular
> Cocoon pipeline using the cocoon:/ pseudo-protocol.
Wouldn't it be _much_ easier to use xalan extensions for this purpose?
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xalan="http://xml.apache.org/xalan">
<xsl:param name="parameter_xpath"/>
...
... select="xalan:evaluate($parameter_xpath)"
HTH
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Sandor Spruit <sa...@cs.uu.nl>.
David wrote:
> I am writing a cocoon transformer and need to know when any of
> multiple xpaths match. I'm sure there must be a be a more efficient
> way then converting it to a DOM document and then running each xpath
> to get the nodelist of each.
Don't know about the best way, but I had a similar problem recently:
I wanted to apply a transformation to specific elements, pointed to by
an XPath expression. The basic problem was that XSLT will not allow
a variable where it expects an XPath, i.e. xsl:template match="$xpath".
One of our students came up with this idea: create the *stylesheet* in a
separate (internal) Cocoon pipeline. Create a placeholder in your XSLT
where you'd normally insert an XPath expression, i.e. 'please-replace-me',
and define a variable for this stylesheet. Write a simple stylesheet to copy
the "stylesheet" template, but replacing the placeholder with your XPath.
Use the result of this pipeline ('a dynamic stylesheet') from your regular
Cocoon pipeline using the cocoon:/ pseudo-protocol.
This works like a charm; the approach can be expanded to work with
multiple XPath expressions. Hope my explanation it clear enough. I'd
post an example, but it's on our server my laptop. Maybe later?
cheers,
Sandor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by David <co...@max-imp.com>.
Thanks for all the help. I will not be able to work on this for a while
so I don't have anything to show right now.
Thanks
David
Geert Josten wrote:
> If you have a working version of your XSL, send me a copy. I might find
> a moment to look for some speed improvements..
>
> Cheers,
> Geert
>
> David wrote:
>
>> Its a very interesting way of doing it but I am worried about speed. I
>> had an idea VERY similar to it but am worried about speed. Yours would
>> probably be faster than what i was thinking. I will consider this as
>> an possible solution. Even if it isn't the best solution I could
>> always do this for now and then rewrite it to use <xsl:next-match/>
>> when xalan supports it.(I am pretty currently doesn't but it might...)
>>
>> I do not know much about STX but I am sure it can be used to solve the
>> problem -- and it would be faster. The only issue I have with that
>> solution is that I am pretty sure its 'xpaths' (stxpaths) are a dumbed
>> down version of xpaths that do not have stuff like preceeding-sibilings.
>>
>> David
>>
>>
>> Geert Josten wrote:
>>
>>> David,
>>>
>>> Fidling around a bit brought me to the XSL you will find below. Some
>>> notes though.
>>>
>>> Particularly the part that multiple values have to be added to the
>>> same attribute makes it quite difficult. I have for convenience
>>> chosen to add separate class elements to the img content. You could
>>> merge these to a class attribute with a separate transform.
>>>
>>> I am very sure this stylesheet can be optimized a lot. It now has to
>>> iterate through as many modes as there are xpaths + 2, which is not
>>> good for performance. This could be optimizes if more knowledge is
>>> added to the xpaths.xml. For instance by clustering less and more
>>> exact matches into a group and converting the matches in this group
>>> to a choose construct inside a template.
>>>
>>> I hope this XSL gives you a jump start or can give you some
>>> inspiration for futher problems..
>>>
>>> By the way, I saw your cross post on the dev list and am curious to
>>> the STX solution as well.
>>>
>>> Cheers,
>>> Geert
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>>
>>> <!-- $Id$ -->
>>>
>>> <xsl:stylesheet version="1.0"
>>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>>> xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
>>>
>>> xmlns:xpaths="xpaths"
>>> xmlns:xhtml="xhtml"
>>> >
>>>
>>> <!--+ ==============================================================
>>> | output
>>> +-->
>>>
>>> <xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
>>>
>>> <xsl:output method="xml"
>>> version="1.0" encoding="utf-8" indent="yes" />
>>>
>>> <!--+ ==============================================================
>>> | default templates
>>> +-->
>>>
>>> <xsl:template match="@*|node()">
>>> <xsl:copy>
>>> <xsl:apply-templates select="@*|node()" />
>>> </xsl:copy>
>>> </xsl:template>
>>>
>>> <xsl:template match="*">
>>> <xsl:element name="{name()}">
>>> <xsl:apply-templates select="@*|node()" />
>>> </xsl:element>
>>> </xsl:template>
>>>
>>> <xsl:template match="xpaths:*">
>>> <xsl:message terminate="yes">
>>> Unknown or incorrect template instruction <xsl:value-of
>>> select="name()" /> within context <xsl:value-of
>>> select="name(parent::*)"/>
>>> </xsl:message>
>>> </xsl:template>
>>>
>>> <!--+ ==============================================================
>>> | root template
>>> +-->
>>>
>>> <xsl:template match="/">
>>> <xsl:apply-templates select="xpaths:xpaths" />
>>> </xsl:template>
>>>
>>> <xsl:template match="xpaths:xpaths">
>>> <myxsl:stylesheet version="1.0">
>>>
>>> <xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
>>> <xsl:copy />
>>> </xsl:for-each>
>>>
>>> <myxsl:output method="xml"
>>> version="1.0" encoding="utf-8" indent="yes" />
>>>
>>> <myxsl:template match="/|@*|node()">
>>> <myxsl:copy>
>>> <myxsl:apply-templates select="." mode="xpath1"/>
>>> </myxsl:copy>
>>> </myxsl:template>
>>>
>>> <xsl:apply-templates select="xpaths:xpath" />
>>>
>>> <myxsl:template match="/|@*|node()"
>>> mode="xpath{count(xpaths:xpath) + 1}">
>>> <myxsl:apply-templates select="@*|node()" />
>>> </myxsl:template>
>>> </myxsl:stylesheet>
>>> </xsl:template>
>>>
>>> <xsl:template match="xpaths:xpath">
>>> <!-- default copying -->
>>> <myxsl:template match="/|@*|node()" mode="xpath{position()}">
>>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>>> </myxsl:template>
>>>
>>> <!-- special case -->
>>> <myxsl:template match="{@match}" mode="xpath{position()}">
>>> <xsl:apply-templates select="node()" />
>>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>>> </myxsl:template>
>>> </xsl:template>
>>>
>>> <xsl:template match="xpaths:literal">
>>> <xsl:apply-templates select="node()" />
>>> </xsl:template>
>>>
>>> </xsl:stylesheet>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
If you have a working version of your XSL, send me a copy. I might find a moment to look for some
speed improvements..
Cheers,
Geert
David wrote:
> Its a very interesting way of doing it but I am worried about speed. I
> had an idea VERY similar to it but am worried about speed. Yours would
> probably be faster than what i was thinking. I will consider this as an
> possible solution. Even if it isn't the best solution I could always do
> this for now and then rewrite it to use <xsl:next-match/> when xalan
> supports it.(I am pretty currently doesn't but it might...)
>
> I do not know much about STX but I am sure it can be used to solve the
> problem -- and it would be faster. The only issue I have with that
> solution is that I am pretty sure its 'xpaths' (stxpaths) are a dumbed
> down version of xpaths that do not have stuff like preceeding-sibilings.
>
> David
>
>
> Geert Josten wrote:
>
>> David,
>>
>> Fidling around a bit brought me to the XSL you will find below. Some
>> notes though.
>>
>> Particularly the part that multiple values have to be added to the
>> same attribute makes it quite difficult. I have for convenience chosen
>> to add separate class elements to the img content. You could merge
>> these to a class attribute with a separate transform.
>>
>> I am very sure this stylesheet can be optimized a lot. It now has to
>> iterate through as many modes as there are xpaths + 2, which is not
>> good for performance. This could be optimizes if more knowledge is
>> added to the xpaths.xml. For instance by clustering less and more
>> exact matches into a group and converting the matches in this group to
>> a choose construct inside a template.
>>
>> I hope this XSL gives you a jump start or can give you some
>> inspiration for futher problems..
>>
>> By the way, I saw your cross post on the dev list and am curious to
>> the STX solution as well.
>>
>> Cheers,
>> Geert
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <!-- $Id$ -->
>>
>> <xsl:stylesheet version="1.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
>>
>> xmlns:xpaths="xpaths"
>> xmlns:xhtml="xhtml"
>> >
>>
>> <!--+ ==============================================================
>> | output
>> +-->
>>
>> <xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
>>
>> <xsl:output method="xml"
>> version="1.0" encoding="utf-8" indent="yes" />
>>
>> <!--+ ==============================================================
>> | default templates
>> +-->
>>
>> <xsl:template match="@*|node()">
>> <xsl:copy>
>> <xsl:apply-templates select="@*|node()" />
>> </xsl:copy>
>> </xsl:template>
>>
>> <xsl:template match="*">
>> <xsl:element name="{name()}">
>> <xsl:apply-templates select="@*|node()" />
>> </xsl:element>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:*">
>> <xsl:message terminate="yes">
>> Unknown or incorrect template instruction <xsl:value-of
>> select="name()" /> within context <xsl:value-of
>> select="name(parent::*)"/>
>> </xsl:message>
>> </xsl:template>
>>
>> <!--+ ==============================================================
>> | root template
>> +-->
>>
>> <xsl:template match="/">
>> <xsl:apply-templates select="xpaths:xpaths" />
>> </xsl:template>
>>
>> <xsl:template match="xpaths:xpaths">
>> <myxsl:stylesheet version="1.0">
>>
>> <xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
>> <xsl:copy />
>> </xsl:for-each>
>>
>> <myxsl:output method="xml"
>> version="1.0" encoding="utf-8" indent="yes" />
>>
>> <myxsl:template match="/|@*|node()">
>> <myxsl:copy>
>> <myxsl:apply-templates select="." mode="xpath1"/>
>> </myxsl:copy>
>> </myxsl:template>
>>
>> <xsl:apply-templates select="xpaths:xpath" />
>>
>> <myxsl:template match="/|@*|node()"
>> mode="xpath{count(xpaths:xpath) + 1}">
>> <myxsl:apply-templates select="@*|node()" />
>> </myxsl:template>
>> </myxsl:stylesheet>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:xpath">
>> <!-- default copying -->
>> <myxsl:template match="/|@*|node()" mode="xpath{position()}">
>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>> </myxsl:template>
>>
>> <!-- special case -->
>> <myxsl:template match="{@match}" mode="xpath{position()}">
>> <xsl:apply-templates select="node()" />
>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>> </myxsl:template>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:literal">
>> <xsl:apply-templates select="node()" />
>> </xsl:template>
>>
>> </xsl:stylesheet>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--
Drs. G.P.H. Josten
Consultant
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken
wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
Hi David,
Here one that doesn't need all the stepping through the modes. But it does require you to put more
effort in the configurating file..
IN:
<?xml version="1.0"?>
<xpaths:xpaths xmlns:xpaths="xpaths" xmlns:xhtml="xhtml">
<xpaths:xpath match="xhtml:img">
<xpaths:attribute name="class">
<xpaths:text>imgclass1</xpaths:text>
<xpaths:if test="@id='more-exact'"> imgclass2</xpaths:if>
</xpaths:attribute>
</xpaths:xpath>
<xpaths:xpath match="xhtml:p">
<xpaths:attribute name="class">pclass</xpaths:attribute>
</xpaths:xpath>
</xpaths:xpaths>
XSL:
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
xmlns:xpaths="xpaths"
xmlns:xhtml="xhtml"
>
<!--+ ==============================================================
| output
+-->
<xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
<xsl:output method="xml"
version="1.0" encoding="utf-8" indent="yes" />
<!--+ ==============================================================
| default templates
+-->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()" />
</xsl:copy>
</xsl:template>
<xsl:template match="*">
<xsl:element name="{name()}">
<xsl:apply-templates select="@*|node()" />
</xsl:element>
</xsl:template>
<xsl:template match="xpaths:*">
<xsl:message terminate="yes">
Unknown or incorrect template instruction <xsl:value-of select="name()" /> within context
<xsl:value-of select="name(parent::*)"/>
</xsl:message>
</xsl:template>
<!--+ ==============================================================
| root template
+-->
<xsl:template match="/">
<xsl:apply-templates select="xpaths:xpaths" />
</xsl:template>
<xsl:template match="xpaths:xpaths">
<myxsl:stylesheet version="1.0">
<xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
<xsl:copy />
</xsl:for-each>
<myxsl:output method="xml"
version="1.0" encoding="utf-8" indent="yes" />
<myxsl:template match="/|@*|node()">
<myxsl:copy>
<myxsl:apply-templates select="@*|node()" />
</myxsl:copy>
</myxsl:template>
<xsl:apply-templates select="xpaths:xpath" />
</myxsl:stylesheet>
</xsl:template>
<xsl:template match="xpaths:xpath">
<!-- special case -->
<myxsl:template match="{@match}">
<myxsl:copy>
<myxsl:apply-templates select="@*" />
<xsl:apply-templates select="node()" />
<myxsl:apply-templates select="node()" />
</myxsl:copy>
</myxsl:template>
</xsl:template>
<xsl:template match="xpaths:attribute">
<myxsl:attribute>
<xsl:apply-templates select="@name|node()" />
</myxsl:attribute>
</xsl:template>
<xsl:template match="xpaths:if">
<myxsl:if>
<xsl:apply-templates select="@test|node()" />
</myxsl:if>
</xsl:template>
<xsl:template match="xpaths:text">
<myxsl:text>
<xsl:apply-templates select="node()" />
</myxsl:text>
</xsl:template>
</xsl:stylesheet>
Cheers,
Geertr
David wrote:
> Its a very interesting way of doing it but I am worried about speed. I
> had an idea VERY similar to it but am worried about speed. Yours would
> probably be faster than what i was thinking. I will consider this as an
> possible solution. Even if it isn't the best solution I could always do
> this for now and then rewrite it to use <xsl:next-match/> when xalan
> supports it.(I am pretty currently doesn't but it might...)
>
> I do not know much about STX but I am sure it can be used to solve the
> problem -- and it would be faster. The only issue I have with that
> solution is that I am pretty sure its 'xpaths' (stxpaths) are a dumbed
> down version of xpaths that do not have stuff like preceeding-sibilings.
>
> David
>
>
> Geert Josten wrote:
>
>> David,
>>
>> Fidling around a bit brought me to the XSL you will find below. Some
>> notes though.
>>
>> Particularly the part that multiple values have to be added to the
>> same attribute makes it quite difficult. I have for convenience chosen
>> to add separate class elements to the img content. You could merge
>> these to a class attribute with a separate transform.
>>
>> I am very sure this stylesheet can be optimized a lot. It now has to
>> iterate through as many modes as there are xpaths + 2, which is not
>> good for performance. This could be optimizes if more knowledge is
>> added to the xpaths.xml. For instance by clustering less and more
>> exact matches into a group and converting the matches in this group to
>> a choose construct inside a template.
>>
>> I hope this XSL gives you a jump start or can give you some
>> inspiration for futher problems..
>>
>> By the way, I saw your cross post on the dev list and am curious to
>> the STX solution as well.
>>
>> Cheers,
>> Geert
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <!-- $Id$ -->
>>
>> <xsl:stylesheet version="1.0"
>> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>> xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
>>
>> xmlns:xpaths="xpaths"
>> xmlns:xhtml="xhtml"
>> >
>>
>> <!--+ ==============================================================
>> | output
>> +-->
>>
>> <xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
>>
>> <xsl:output method="xml"
>> version="1.0" encoding="utf-8" indent="yes" />
>>
>> <!--+ ==============================================================
>> | default templates
>> +-->
>>
>> <xsl:template match="@*|node()">
>> <xsl:copy>
>> <xsl:apply-templates select="@*|node()" />
>> </xsl:copy>
>> </xsl:template>
>>
>> <xsl:template match="*">
>> <xsl:element name="{name()}">
>> <xsl:apply-templates select="@*|node()" />
>> </xsl:element>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:*">
>> <xsl:message terminate="yes">
>> Unknown or incorrect template instruction <xsl:value-of
>> select="name()" /> within context <xsl:value-of
>> select="name(parent::*)"/>
>> </xsl:message>
>> </xsl:template>
>>
>> <!--+ ==============================================================
>> | root template
>> +-->
>>
>> <xsl:template match="/">
>> <xsl:apply-templates select="xpaths:xpaths" />
>> </xsl:template>
>>
>> <xsl:template match="xpaths:xpaths">
>> <myxsl:stylesheet version="1.0">
>>
>> <xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
>> <xsl:copy />
>> </xsl:for-each>
>>
>> <myxsl:output method="xml"
>> version="1.0" encoding="utf-8" indent="yes" />
>>
>> <myxsl:template match="/|@*|node()">
>> <myxsl:copy>
>> <myxsl:apply-templates select="." mode="xpath1"/>
>> </myxsl:copy>
>> </myxsl:template>
>>
>> <xsl:apply-templates select="xpaths:xpath" />
>>
>> <myxsl:template match="/|@*|node()"
>> mode="xpath{count(xpaths:xpath) + 1}">
>> <myxsl:apply-templates select="@*|node()" />
>> </myxsl:template>
>> </myxsl:stylesheet>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:xpath">
>> <!-- default copying -->
>> <myxsl:template match="/|@*|node()" mode="xpath{position()}">
>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>> </myxsl:template>
>>
>> <!-- special case -->
>> <myxsl:template match="{@match}" mode="xpath{position()}">
>> <xsl:apply-templates select="node()" />
>> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
>> </myxsl:template>
>> </xsl:template>
>>
>> <xsl:template match="xpaths:literal">
>> <xsl:apply-templates select="node()" />
>> </xsl:template>
>>
>> </xsl:stylesheet>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--
Drs. G.P.H. Josten
Consultant
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken
wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by David <co...@max-imp.com>.
Its a very interesting way of doing it but I am worried about speed. I
had an idea VERY similar to it but am worried about speed. Yours would
probably be faster than what i was thinking. I will consider this as an
possible solution. Even if it isn't the best solution I could always do
this for now and then rewrite it to use <xsl:next-match/> when xalan
supports it.(I am pretty currently doesn't but it might...)
I do not know much about STX but I am sure it can be used to solve the
problem -- and it would be faster. The only issue I have with that
solution is that I am pretty sure its 'xpaths' (stxpaths) are a dumbed
down version of xpaths that do not have stuff like preceeding-sibilings.
David
Geert Josten wrote:
> David,
>
> Fidling around a bit brought me to the XSL you will find below. Some
> notes though.
>
> Particularly the part that multiple values have to be added to the same
> attribute makes it quite difficult. I have for convenience chosen to add
> separate class elements to the img content. You could merge these to a
> class attribute with a separate transform.
>
> I am very sure this stylesheet can be optimized a lot. It now has to
> iterate through as many modes as there are xpaths + 2, which is not good
> for performance. This could be optimizes if more knowledge is added to
> the xpaths.xml. For instance by clustering less and more exact matches
> into a group and converting the matches in this group to a choose
> construct inside a template.
>
> I hope this XSL gives you a jump start or can give you some inspiration
> for futher problems..
>
> By the way, I saw your cross post on the dev list and am curious to the
> STX solution as well.
>
> Cheers,
> Geert
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <!-- $Id$ -->
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
>
> xmlns:xpaths="xpaths"
> xmlns:xhtml="xhtml"
> >
>
> <!--+ ==============================================================
> | output
> +-->
>
> <xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
>
> <xsl:output method="xml"
> version="1.0" encoding="utf-8" indent="yes" />
>
> <!--+ ==============================================================
> | default templates
> +-->
>
> <xsl:template match="@*|node()">
> <xsl:copy>
> <xsl:apply-templates select="@*|node()" />
> </xsl:copy>
> </xsl:template>
>
> <xsl:template match="*">
> <xsl:element name="{name()}">
> <xsl:apply-templates select="@*|node()" />
> </xsl:element>
> </xsl:template>
>
> <xsl:template match="xpaths:*">
> <xsl:message terminate="yes">
> Unknown or incorrect template instruction <xsl:value-of
> select="name()" /> within context <xsl:value-of select="name(parent::*)"/>
> </xsl:message>
> </xsl:template>
>
> <!--+ ==============================================================
> | root template
> +-->
>
> <xsl:template match="/">
> <xsl:apply-templates select="xpaths:xpaths" />
> </xsl:template>
>
> <xsl:template match="xpaths:xpaths">
> <myxsl:stylesheet version="1.0">
>
> <xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
> <xsl:copy />
> </xsl:for-each>
>
> <myxsl:output method="xml"
> version="1.0" encoding="utf-8" indent="yes" />
>
> <myxsl:template match="/|@*|node()">
> <myxsl:copy>
> <myxsl:apply-templates select="." mode="xpath1"/>
> </myxsl:copy>
> </myxsl:template>
>
> <xsl:apply-templates select="xpaths:xpath" />
>
> <myxsl:template match="/|@*|node()"
> mode="xpath{count(xpaths:xpath) + 1}">
> <myxsl:apply-templates select="@*|node()" />
> </myxsl:template>
> </myxsl:stylesheet>
> </xsl:template>
>
> <xsl:template match="xpaths:xpath">
> <!-- default copying -->
> <myxsl:template match="/|@*|node()" mode="xpath{position()}">
> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
> </myxsl:template>
>
> <!-- special case -->
> <myxsl:template match="{@match}" mode="xpath{position()}">
> <xsl:apply-templates select="node()" />
> <myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
> </myxsl:template>
> </xsl:template>
>
> <xsl:template match="xpaths:literal">
> <xsl:apply-templates select="node()" />
> </xsl:template>
>
> </xsl:stylesheet>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
David,
Fidling around a bit brought me to the XSL you will find below. Some notes though.
Particularly the part that multiple values have to be added to the same attribute makes it quite
difficult. I have for convenience chosen to add separate class elements to the img content. You
could merge these to a class attribute with a separate transform.
I am very sure this stylesheet can be optimized a lot. It now has to iterate through as many modes
as there are xpaths + 2, which is not good for performance. This could be optimizes if more
knowledge is added to the xpaths.xml. For instance by clustering less and more exact matches into a
group and converting the matches in this group to a choose construct inside a template.
I hope this XSL gives you a jump start or can give you some inspiration for futher problems..
By the way, I saw your cross post on the dev list and am curious to the STX solution as well.
Cheers,
Geert
<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id$ -->
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:myxsl="http://www.w3.org/1999/XSL/TransformAlias"
xmlns:xpaths="xpaths"
xmlns:xhtml="xhtml"
>
<!--+ ==============================================================
| output
+-->
<xsl:namespace-alias stylesheet-prefix="myxsl" result-prefix="xsl"/>
<xsl:output method="xml"
version="1.0" encoding="utf-8" indent="yes" />
<!--+ ==============================================================
| default templates
+-->
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()" />
</xsl:copy>
</xsl:template>
<xsl:template match="*">
<xsl:element name="{name()}">
<xsl:apply-templates select="@*|node()" />
</xsl:element>
</xsl:template>
<xsl:template match="xpaths:*">
<xsl:message terminate="yes">
Unknown or incorrect template instruction <xsl:value-of select="name()" /> within context
<xsl:value-of select="name(parent::*)"/>
</xsl:message>
</xsl:template>
<!--+ ==============================================================
| root template
+-->
<xsl:template match="/">
<xsl:apply-templates select="xpaths:xpaths" />
</xsl:template>
<xsl:template match="xpaths:xpaths">
<myxsl:stylesheet version="1.0">
<xsl:for-each select="namespace::*[not(name() = 'xpaths')]">
<xsl:copy />
</xsl:for-each>
<myxsl:output method="xml"
version="1.0" encoding="utf-8" indent="yes" />
<myxsl:template match="/|@*|node()">
<myxsl:copy>
<myxsl:apply-templates select="." mode="xpath1"/>
</myxsl:copy>
</myxsl:template>
<xsl:apply-templates select="xpaths:xpath" />
<myxsl:template match="/|@*|node()" mode="xpath{count(xpaths:xpath) + 1}">
<myxsl:apply-templates select="@*|node()" />
</myxsl:template>
</myxsl:stylesheet>
</xsl:template>
<xsl:template match="xpaths:xpath">
<!-- default copying -->
<myxsl:template match="/|@*|node()" mode="xpath{position()}">
<myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
</myxsl:template>
<!-- special case -->
<myxsl:template match="{@match}" mode="xpath{position()}">
<xsl:apply-templates select="node()" />
<myxsl:apply-templates select="." mode="xpath{position() + 1}"/>
</myxsl:template>
</xsl:template>
<xsl:template match="xpaths:literal">
<xsl:apply-templates select="node()" />
</xsl:template>
</xsl:stylesheet>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
Testing..
Geert Josten wrote:
> I take the challenge to make this work in XSL. Just give me about 15 min.
>
> :-)
>
> David wrote:
>
>> Geert Josten wrote:
>>
>>> Hi David,
>>>
>>> Actually, it has. Sandor suggested to generate an XSL using the
>>> xpaths you want to match as input. As long as not every requests
>>> needs a new XSL, this will be fairly efficient. And though a DOM tree
>>> is being build from the input SAX events for the XSL transform, you
>>> do not need to bother about it and neither about converting it to SAX
>>> again.
>>>
>>> It could be more efficient to write a XPath testing Transformer, but
>>> doing it without DOM will require you to put a lot of information
>>> into memory, parse the xpath expressions and match each event against
>>> the expressions. I have seen attempts in other languages and I cannot
>>> recommend this procedure, not for full Xpath support ;-P..
>>>
>>> In short, I think generating an XSL is by far the easiest way and
>>> gives you full power at the same time. Let know if you need help on
>>> this...
>>>
>>> Cheers,
>>> Geert
>>
>>
>>
>> Oh I see. Even though the xpaths will not change much I do not believe
>> XSL will work. For example I have two xpaths that both should match
>> the same thing. Eg
>> -----------------
>> <template match="//xhtml:img">
>> <copy>
>> <attribute name="class" select="concat('match1 ', @class)"/>
>> </copy>
>> </template>
>> <template match="//xhtml:img[@id='more-exact']">
>> <copy>
>> <attribute name="class" select="concat('match2 ', @class)"/>
>> </copy>
>> </template>
>> ----------------
>>
>> Now if I had xhtml like this:'
>> ----------------
>> <img/>
>> <img id="more-exact'/>
>> --------------
>> the results obviously will be
>> ---------------
>> <img class="match1"/>
>> <img id="more-exact" class="match2"/>
>> --------------
>> i WANT the results to be
>> ---------------
>> <img class="match1"/>
>> <img id="more-exact" class="match1 match2"/>
>> --------------
>> sooo.. pretty much I want BOTH xpaths to match; not just the highest
>> prioritized one.
>>
>> Calling the first template from the 2nd one is not an option. This
>> example is simplified. In the actual problem there will be many more
>> xpaths and we would need to dynamically create the xsl files... and if
>> one template needs to call another one I have no idea how I would
>> figure that out. (Some how I would have to know that a group of xpaths
>> all match something so the templates need to call each other.)
>>
>> This is why I am not using an xsl file. Anyone know of a good way to
>> do this in xsl? (I came up with one or two ways of doing it but it in
>> no way an elegant solution -- and probably extremely slow.) MAYBE if
>> xsl:next-match was supported I could do this -- but xalan does not
>> seem to have support for it yet.
>>
>> So who has a brilliant way of doing this? :-)
>>
>> David
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
--
Drs. G.P.H. Josten
Consultant
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken
wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
I take the challenge to make this work in XSL. Just give me about 15 min.
:-)
David wrote:
> Geert Josten wrote:
>
>> Hi David,
>>
>> Actually, it has. Sandor suggested to generate an XSL using the xpaths
>> you want to match as input. As long as not every requests needs a new
>> XSL, this will be fairly efficient. And though a DOM tree is being
>> build from the input SAX events for the XSL transform, you do not need
>> to bother about it and neither about converting it to SAX again.
>>
>> It could be more efficient to write a XPath testing Transformer, but
>> doing it without DOM will require you to put a lot of information into
>> memory, parse the xpath expressions and match each event against the
>> expressions. I have seen attempts in other languages and I cannot
>> recommend this procedure, not for full Xpath support ;-P..
>>
>> In short, I think generating an XSL is by far the easiest way and
>> gives you full power at the same time. Let know if you need help on
>> this...
>>
>> Cheers,
>> Geert
>
>
> Oh I see. Even though the xpaths will not change much I do not believe
> XSL will work. For example I have two xpaths that both should match the
> same thing. Eg
> -----------------
> <template match="//xhtml:img">
> <copy>
> <attribute name="class" select="concat('match1 ', @class)"/>
> </copy>
> </template>
> <template match="//xhtml:img[@id='more-exact']">
> <copy>
> <attribute name="class" select="concat('match2 ', @class)"/>
> </copy>
> </template>
> ----------------
>
> Now if I had xhtml like this:'
> ----------------
> <img/>
> <img id="more-exact'/>
> --------------
> the results obviously will be
> ---------------
> <img class="match1"/>
> <img id="more-exact" class="match2"/>
> --------------
> i WANT the results to be
> ---------------
> <img class="match1"/>
> <img id="more-exact" class="match1 match2"/>
> --------------
> sooo.. pretty much I want BOTH xpaths to match; not just the highest
> prioritized one.
>
> Calling the first template from the 2nd one is not an option. This
> example is simplified. In the actual problem there will be many more
> xpaths and we would need to dynamically create the xsl files... and if
> one template needs to call another one I have no idea how I would figure
> that out. (Some how I would have to know that a group of xpaths all
> match something so the templates need to call each other.)
>
> This is why I am not using an xsl file. Anyone know of a good way to do
> this in xsl? (I came up with one or two ways of doing it but it in no
> way an elegant solution -- and probably extremely slow.) MAYBE if
> xsl:next-match was supported I could do this -- but xalan does not seem
> to have support for it yet.
>
> So who has a brilliant way of doing this? :-)
>
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--
Drs. G.P.H. Josten
Consultant
Daidalos BV
Source of Innovation
Hoekeindsehof 1-4
2665 JZ Bleiswijk
Tel: +31 (0) 10 850 1200
Fax: +31 (0) 10 850 1199
www.daidalos.nl
De informatie - verzonden in of met dit emailbericht - is afkomstig van Daidalos BV en is
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onbedoeld hebt ontvangen, verzoeken
wij u het te verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by David <co...@max-imp.com>.
Geert Josten wrote:
> Hi David,
>
> Actually, it has. Sandor suggested to generate an XSL using the xpaths
> you want to match as input. As long as not every requests needs a new
> XSL, this will be fairly efficient. And though a DOM tree is being build
> from the input SAX events for the XSL transform, you do not need to
> bother about it and neither about converting it to SAX again.
>
> It could be more efficient to write a XPath testing Transformer, but
> doing it without DOM will require you to put a lot of information into
> memory, parse the xpath expressions and match each event against the
> expressions. I have seen attempts in other languages and I cannot
> recommend this procedure, not for full Xpath support ;-P..
>
> In short, I think generating an XSL is by far the easiest way and gives
> you full power at the same time. Let know if you need help on this...
>
> Cheers,
> Geert
Oh I see. Even though the xpaths will not change much I do not believe
XSL will work. For example I have two xpaths that both should match the
same thing. Eg
-----------------
<template match="//xhtml:img">
<copy>
<attribute name="class" select="concat('match1 ', @class)"/>
</copy>
</template>
<template match="//xhtml:img[@id='more-exact']">
<copy>
<attribute name="class" select="concat('match2 ', @class)"/>
</copy>
</template>
----------------
Now if I had xhtml like this:'
----------------
<img/>
<img id="more-exact'/>
--------------
the results obviously will be
---------------
<img class="match1"/>
<img id="more-exact" class="match2"/>
--------------
i WANT the results to be
---------------
<img class="match1"/>
<img id="more-exact" class="match1 match2"/>
--------------
sooo.. pretty much I want BOTH xpaths to match; not just the highest
prioritized one.
Calling the first template from the 2nd one is not an option. This
example is simplified. In the actual problem there will be many more
xpaths and we would need to dynamically create the xsl files... and if
one template needs to call another one I have no idea how I would figure
that out. (Some how I would have to know that a group of xpaths all
match something so the templates need to call each other.)
This is why I am not using an xsl file. Anyone know of a good way to do
this in xsl? (I came up with one or two ways of doing it but it in no
way an elegant solution -- and probably extremely slow.) MAYBE if
xsl:next-match was supported I could do this -- but xalan does not seem
to have support for it yet.
So who has a brilliant way of doing this? :-)
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by Geert Josten <Ge...@daidalos.nl>.
Hi David,
Actually, it has. Sandor suggested to generate an XSL using the xpaths you want to match as input.
As long as not every requests needs a new XSL, this will be fairly efficient. And though a DOM tree
is being build from the input SAX events for the XSL transform, you do not need to bother about it
and neither about converting it to SAX again.
It could be more efficient to write a XPath testing Transformer, but doing it without DOM will
require you to put a lot of information into memory, parse the xpath expressions and match each
event against the expressions. I have seen attempts in other languages and I cannot recommend this
procedure, not for full Xpath support ;-P..
In short, I think generating an XSL is by far the easiest way and gives you full power at the same
time. Let know if you need help on this...
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: multiple xpaths
Posted by David <co...@max-imp.com>.
David wrote:
> I am writing a cocoon transformer and need to know when any of multiple
> xpaths match. I'm sure there must be a be a more efficient way then
> converting it to a DOM document and then running each xpath to get the
> nodelist of each.
>
> What is the best way to do this?
>
> Thanks,
> David
The responses I have received are very interesting but I do not believe
any of them will help me.
Anyone else?
Thanks :-)
David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org