Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <470E61AB.3010803@apache.org>
Date: Thu, 11 Oct 2007 19:47:23 +0200
From: Grzegorz Kossakowski <gkossakowski@apache.org>
User-Agent: Thunderbird 2.0.0.5 (X11/20070719)
MIME-Version: 1.0
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1 environment objects from a Java XSLT extension
References: <20071010083057.GU21934@localhost.localdomain>
 <dfe834320710101547p6fc281baied44942fdf5bfdf9@mail.gmail.com>
 <20071011132858.GC21934@localhost.localdomain>
In-Reply-To: <20071011132858.GC21934@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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