On 03/12/2007, Florent Georges <lists(_at_)fgeorges(_dot_)org> wrote:
Scott Trenda wrote:
Hi
That's a decent philosophy, but the real-world problem is
that you usually have large chunks of data within your
source document that you don't want in your output.
First I didn't say that was THE answer. But that's a way
of developing with XSLT that one doesn't have usualy when
coming from imperative languages, and that helps to fight
complexity.
Of course the point is not to not control what the
stylesheet does, but to define what it does in places that
ease maintainability.
If you apply-templates to all children indiscriminately
when you only actually want to process a certain subset of
child nodes, then you have a high probability that the
built-in templates will catch that unwanted data,
resulting in unwanted text everywhere in your result,
interspersed with the text you did want.
If the default template rules don't do what you want,
don't use them.
On 03/12/2007, Florent Georges <lists(_at_)fgeorges(_dot_)org> wrote:
Scott Trenda wrote:
Hi
That's a decent philosophy, but the real-world problem is
that you usually have large chunks of data within your
source document that you don't want in your output.
First I didn't say that was THE answer. But that's a way
of developing with XSLT that one doesn't have usualy when
coming from imperative languages, and that helps to fight
complexity.
Of course the point is not to not control what the
stylesheet does, but to define what it does in places that
ease maintainability.
If you apply-templates to all children indiscriminately
when you only actually want to process a certain subset of
child nodes, then you have a high probability that the
built-in templates will catch that unwanted data,
resulting in unwanted text everywhere in your result,
interspersed with the text you did want.
If the default template rules don't do what you want,
don't use them.
If I've followed the thread I think you're discussing the choice of
filtering the nodes to be processed using a predicate:
<xsl:apply-templates select="some-nodes[some-filter]"/>
with:
<xsl:template match="some-nodes"> ....
or using a filter at the template match level with no-op templates:
<xsl:apply-templates/>
<xsl:template match="some-nodes"/>
<xsl:template match="some-nodes[some-filter]">....
?
Also, as I had said in the previous response, template
match patterns must be context-free. If you need to select
a node-set that requires a context, you're limited to
apply-templates.
I must confess I don't understand this paragraph.
I kind of understand what Scott means but I'm not sure I agree - in
the above example doesn't the template match pattern in the latter
method give you same level of context as the select in the former?
match="foo" has no context as it will match any <foo/>, but
match="/root/foo" will only match <foo> children of the single <root>
element - which I think is the context you mean.
As for the two techniques, the latter gives you more scope for
overriding, and suits the one-template-per-element design that some
people like (for each input element there will be at least one
non-default template). Also in an IDE you would see all the match
patterns together, which you don't get if the logic is in a predicate
in the select of an apply-templates somewhere.
I tend to use the former, but I can definitely see the merits of using
the latter.
cheers
andrew
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--