xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: #include for <xsp:
Date Sat, 10 Mar 2001 19:05:23 GMT
On Sat, 10 Mar 2001 18:26:20 -0000, Robin Green wrote:

>"Tagunov Anthony" <atagunov@nnt.ru> wrote:
>>This is a second problem that i suffered much
>>when developing XSP:
>>C1 design required that xsp processor was
>>coming first in the Cocoon chain.
>>(dunno if it still true for C2, but maybe it would
>>be good to search for a cocoon-indepenedent
>>Having in mind that xsp processor has my file
>>as input, i knew that i could with some effort
>>apply consequential transforms to it:
>>  -- run consequential logicsheets
>>  -- use multiple taglibs
>>But what i really wanted was to INCLUDE
>>some xml into my source file from another
>>file (smth similar to #include in .c)
>What's wrong with xsl:include, xsl:import

xsl:include and xsl:import are fine, but they are xsl,
they include something into the stylesheet, and that's
not exactly what i want:

(going back to my example, i have metadata describing
RDBMS table (meta.xml). I want this data to be used
(well, these are the screens i need to build up an app
for editing this table over web)
what i want is:

edit1.xml :    edit1.xml--(include meta.xml)-->--(transform1=taglib1)-->x
edit2.xml :    edit2.xml--(include meta.xml)-->--(transform2=taglib2)-->x
edit3.xml :    edit3.xml--(include meta.xml)-->--(transform3=taglib3)-->x

of cource i can do it in the following way: have instead
of meta.xml meta.xsl (assuming i'm in Cocoon) and have it as followes:
<xsl:template><xsl:match="metadata"><table name=..>...</xsl:match></xsl:stylesheet>,
so instead of the scheme that i have above i have

edit1.xml :    edit1.xml--(transform-to-insert-metadata)-->--(transform1=taglib1)-->x
edit2.xml :    edit2.xml--(transform-to-insert-metadata)-->--(transform2=taglib2)-->x
edit3.xml :    edit3.xml--(transform-to-insert-metadata)-->--(transform3=taglib3)-->x

this is a solution, but is not the same, is it? :)

On Sat, 10 Mar 2001 18:33:05 +0000 (GMT), Matt Sergeant wrote:
>And don't forget the util: taglib.
As far as i understand, this include happens at runtime, so this is what
you call "application of taglibs in parallel", isn't it, Matt ? ;)
And as you see from my prev example i actully want to include SOURCE
from a file, source that contains tags that will be processed by the taglibs
(including, but not limited to tags that are directly taglib invocations, like

On Sat, 10 Mar 2001 18:26:20 -0000, Robin Green wrote:

>.. and external entities?

That is almost what i need, they provide exactly the functionality i want,
inclusion that may even include stuff like <request:get-parameter../>.
It is possible to use them.
The reasons i don't use them are:
a) the syntax is somewhat not very evident and friendly (having to
define a <!DOCTYPE> section..
b) in C1 architecture the caching system is unable to detect changes
in file included in this fashion

The external enteties are great, but still, wouldn't it be beneficial to have
a more evident syntax for the same purpose? 

(Plus the ablility for
the caching mechanisms to know that the timestamp on the included
file should be taken into consideration?)

Best regards, Tagunov Anthony

View raw message