You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Tobia Conforto <to...@linux.it> on 2007/10/10 10:30:57 UTC
Cocoon 2.1 environment objects from a Java XSLT extension
Hi
I'm rewriting some functionality into Java XSLT extensions, for
performance reasons.
For now I'm just writing a Java class, copying it to WEB-INF/classes and
calling its static methods from XSLT as such:
<xsl:value-of select="myclass:myMethod($whatever)"
xmlns:myclass="http://xml.apache.org/xalan/java/MyClass"/>
This works, but I need to access the standard Cocoon environment objects
(Request would suffice) from my Java class.
Should I pass the whole request object to the stylesheet as a parameter
and then pass it on to every invocation of my methods?
How do I pass the request object to the stylesheet? I couldn't do it.
Is there a better way?
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1 environment objects from a Java XSLT extension
Posted by Tobia Conforto <to...@linux.it>.
Grzegorz Kossakowski wrote:
> I'm not sure if it's going to fit in your case but I would suggest to
> take a look at Cocoon's quite powerful LinkRewriterTransformer[1].
Very interesting, thanks.
It seems to fit my case perfectly!
> Basically all you would need to do is to implement your own input
> module (quite simple task) and configure transformer so it uses your
> own input module.
So I would put my SQL logic in the input module... makes sense!
> I strongly agree that using extension functions in your case that
> access external that is *NOT* a good idea.
Very well, lesson taken.
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1 environment objects from a Java XSLT extension
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Tobia Conforto pisze:
> solprovider@apache.org wrote:
>> XSLT Extensions assist formatting. Data collection belongs in the XML
>> generation phase. Using XSLT Extensions to generate data is a very
>> bad practice. What are the requirements?
>
> Let me explain better.
>
> I need to translate URIs in a XML document, in the middle of a pipeline,
> fetching relevant information from a SQL database. "In the middle of a
> pipeline" means that there are various other steps before it, so I
> cannot fetch this SQL data in the initial generator.
>
> At first I tried to have a sub-pipeline do the job, using the document()
> XPath function with a cocoon: schema, but it was too slow.
>
> My next (and current) idea is transforming the XML with XSLT, while
> coding the actual URI transformations (including the SQL queries) as a
> Java extension function, to be called from XSLT where appropriate.
>
> I'm hitting a wall, because I need a DataSourceComponent to be able to
> make SQL queries, but a Java XSLT extension class doesn't have any
> access to Cocoon's object model (that I can see.)
>
> I cannot pass the DataSourceComponent, or any other interesting object,
> from the sitemap to my extension function, passing through the XSLT as a
> parameter, because XSLT parameters get passed from the sitemap as strings.
>
> Suggestions are welcome.
>
> My last resort is doing everything as a custom transformer, but I'd like
> to avoid it, as I'm not too keen on coding in Sax what can easily be
> dealt with in XSLT (changing a bunch of attribute values.) Although it
> wouldn't be too hard with Sax either...
I'm not sure if it's going to fit in your case but I would suggest to take a look at Cocoon's quite
powerful LinkRewriterTransformer[1].
Basically all you would need to do is to implement your own input module (quite simple task) and
configure transformer so it uses your own input module.
I strongly agree that using extension functions in your case that access external that is *NOT* a
good idea.
[1] http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/transformation/LinkRewriterTransformer.html
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1 environment objects from a Java XSLT extension
Posted by Tobia Conforto <to...@linux.it>.
solprovider@apache.org wrote:
> XSLT Extensions assist formatting. Data collection belongs in the XML
> generation phase. Using XSLT Extensions to generate data is a very
> bad practice. What are the requirements?
Let me explain better.
I need to translate URIs in a XML document, in the middle of a pipeline,
fetching relevant information from a SQL database. "In the middle of a
pipeline" means that there are various other steps before it, so I
cannot fetch this SQL data in the initial generator.
At first I tried to have a sub-pipeline do the job, using the document()
XPath function with a cocoon: schema, but it was too slow.
My next (and current) idea is transforming the XML with XSLT, while
coding the actual URI transformations (including the SQL queries) as a
Java extension function, to be called from XSLT where appropriate.
I'm hitting a wall, because I need a DataSourceComponent to be able to
make SQL queries, but a Java XSLT extension class doesn't have any
access to Cocoon's object model (that I can see.)
I cannot pass the DataSourceComponent, or any other interesting object,
from the sitemap to my extension function, passing through the XSLT as a
parameter, because XSLT parameters get passed from the sitemap as strings.
Suggestions are welcome.
My last resort is doing everything as a custom transformer, but I'd like
to avoid it, as I'm not too keen on coding in Sax what can easily be
dealt with in XSLT (changing a bunch of attribute values.) Although it
wouldn't be too hard with Sax either...
Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1 environment objects from a Java XSLT extension
Posted by so...@apache.org.
Yes. There is a better method.
XSLT Extensions assist formatting. Data collection belongs in the XML
generation phase. Using XSLT Extensions to generate data is a very
bad practice.
What are the requirements? You want some information for use in
creating the output. The information is in the Request. What
information? How much information? How many places will it appear?
Will different information be needed at different places? Possible
methods include:
- Use the standard variables:
http://solprovider.com/lenya/variablescommon#request
http://solprovider.com/lenya/variablescocoon
- Aggregate the RequestGenerator:
http://cocoon.apache.org/2.1/userdocs/request-generator.html
Very easy. Most work handled with XSL.
- Custom Generator
To aggregate non-standard information.
- Custom InputModule:
To pass just a parameter.
Custom components are not difficult for your third one. The first one
or two can be difficult due to lack of documentation and that most
environment variables are deliberately hidden to frustrate new
developers. Cocoon blocks access to some critical parameters and
hides others in maps without access to the names of those parameters.
This may promote elitism, but may result from poor design.
solprovider
On 10/10/07, Tobia Conforto <to...@linux.it> wrote:
> I'm rewriting some functionality into Java XSLT extensions, for
> performance reasons.
>
> For now I'm just writing a Java class, copying it to WEB-INF/classes and
> calling its static methods from XSLT as such:
> <xsl:value-of select="myclass:myMethod($whatever)"
> xmlns:myclass="http://xml.apache.org/xalan/java/MyClass"/>
>
> This works, but I need to access the standard Cocoon environment objects
> (Request would suffice) from my Java class.
>
> Should I pass the whole request object to the stylesheet as a parameter
> and then pass it on to every invocation of my methods?
> How do I pass the request object to the stylesheet? I couldn't do it.
>
> Is there a better way?
> Tobia
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.1 environment objects from a Java XSLT extension
Posted by Martin Heiden <ma...@netcologne.de>.
Tobia,
Wednesday, October 10, 2007, 10:30:57 AM, you wrote:
TC> This works, but I need to access the standard Cocoon environment objects
TC> (Request would suffice) from my Java class.
TC> Is there a better way?
Just an idea, I never tested it but maybe it's worth to try it:
Did you think about putting the objects you need into a ThreadLocal
variable before you start the transformation?
good luck!
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org