cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Koberg" <...@koberg.com>
Subject RE: DO NOT REPLY [Bug 12235] New: - [PATCH] XPathTransformer
Date Tue, 03 Sep 2002 14:43:46 GMT
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


Mime
View raw message