cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paint...@mc.duke.edu
Subject Re: util:include + xsp problem
Date Thu, 15 Mar 2001 17:15:05 GMT

paint007@mc.duke.edu wrote:
>>
>> Why exactly is using the XInclude processor before the XSP processor a
>> hack?  I'm doing this now so that I can get reusability out of my code
>> (some XML fragments can be shared among different pages).  The caching
>> issue is annoying, but I just touch the including files every time I
change
>> an included file, which is adequate in a development environment.  This
>> won't be an issue for me in production as I'll touch everything when I
>> release new code.

>Because once you move to Cocoon 2, your code will no longer be functional.
>XSP is a Generator (or something that creates XML), and not a Transformer
>(or something that changes XML).

Okay, that's clear enough.  I'm glad to know this now!

>> The bits of code that I'm including are completely independent,
producing
>> their own XML nodes for processing in the xsl files (which are also
>> factored to match the xml and included using xsl:import).  Is there a
>> better way to do this?

>As long as the XSP is static (i.e. not forcing Cocoon to recompile the
>XSP every time a request is received), you can use the util:include or
>such like.  You might consider positioning XInclude after the XSP page.
>If you are combining multiple logicsheets together (which is what it
>sounds like you are doing), then use the namespaces for each logicsheet,
>and let Cocoon worry about assembling the end product.

The XSP documents are static.  At the moment they mostly use the esql
taglib to select data from a db.  I can certainly try the util:include
mechanism.  I'm not sure I understand the rest of your paragraph, but I'll
read some more and play around with it.  In particular, if I put the
XInclude after the XSP, how will the included xml files get processed by
XSP?

An example of what I'm doing is:
One xml file creates a node that will be turned into an HTML form by the
xsl.  The form allows a user to select a few values from drop down lists
and click a button to submit.  The selected values provide parameters for a
query that will be run in a second xml file.  The form action is actually a
third xml file which does nothing but use XInclude to include the first two
xml files.  The resulting XML has a node with the query options (from the
first file) and a node with the results of the query (from the second
file).  The user sees HTML with the results as well as the query form; they
can submit a new query from the results page.

The separation of the two xml makes it very easy to do this without
resorting to conditional logic.  Also, since the query form portion is
farily generic, I can re-use it to drive very different queries in other
parts of the application.  Etc.  A lot of OOP instincts coming in to play
here.

Thanks for your help.

-Christopher




---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message