You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Dzmura <md...@digital-mission.com> on 2000/03/31 00:37:05 UTC
multiple layers of XSLT ...
Hi:
I am trying to do multiple layers of stylesheet-drive XSL transformations to a single
.xml file. (Presently, the number of transformations is two, but it will grow for some
purposes...)
In addition, I have written a simple processor to dynamically add some stuff into
the Document. (In fact, this part is working and doing exactly what I expect it to do...)
To summarize, I want to first run my processor, then apply two levels of XSL transformation,
then format for web presentation. (Of course, I could just use a single level of transformation
and one .xsl file, but that would defeat my purpose of separating the development and
maintenance of the different transformations... something which Cocoon should help
me to do!!)
Continuing on, at first I thought I could simple-mindedly do something like this in the .xml files:
----------
<?cocoon-process type="nav"?> // my processor - this works
<?cocoon-process type="xslt"?>
<?xml-stylesheet href="http://foobar.net/digipath/dphome.xsl" type="text/xsl"?>
<?cocoon-process type="xslt"?>
<?xml-stylesheet href="http://foobar.net/digipath/dpframe.xsl" type="text/xsl"?>
// formatter is the default
----------
Although the individual stylesheets are verified to work, the combination did not
do what I expected... So I went to the Cocoon sources.
What I seemed to find there is that any attempt to execute a Processor with a given
MIME type and web browser type is always going to be associated with the first
matching stylesheet!! In essence, the "dphome.xsl" stylesheet would be applied
for both transformations... Is this correct, or am I missing something??
If so, I am trying to think of a way to eliminate this problem... An obvious candidate is to
remove the <?xml-stylesheet> node after encountering it, so that it will not be selected
the next time through... this is already done with
However, how does this interact with the caching store?? If the store caches Documents,
then it would have to maintain unmodified, virginal copies and make a fresh copy for each
pass through the Engine...
Does anybody have any ideas?? Or am I going about this the wrong way ??
Thanks,
Mark Dzmura
p.s. Another issue with the XSLT processor relates to absolute paths to style sheets..
I have .xml files in multiple levels of subdirectories, but want many of them to refer to
a single stylesheet stored in a directory of stylesheets. However, I have only been able
to do this using a URL to name the stylesheets! If I use a web-based absolute file
name, the XSLT processor cannot find it - the XSLTProcessor code seems to confirm that the
stylesheet file name is computed relative to the location of the .xml file ... which
has unpleasant ramfications for managebility of large sites.
Has anybody else run into this??
--
)))) This email routed via a wireless gateway!! ((((
Re: multiple layers of XSLT ...
Posted by Ulrich Mayring <ul...@denic.de>.
#postgres@digital-mission.com wrote:
>
> name, the XSLT processor cannot find it - the XSLTProcessor code seems to
> confirm that the
> stylesheet file name is computed relative to the location of the .xml file
> ... which
> has unpleasant ramfications for managebility of large sites.
>
> Has anybody else run into this??
Here's how I worked around this one:
<?xml-stylesheet href="http://localhost/central.xsp" type="text/xsl"?>
Of course this is only good for testing on my local machine. But in
deployment you can get the server name from the HTTP request and insert
it instead of localhost.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: multiple layers of XSLT ...
Posted by Mark Dzmura <md...@digital-mission.com>.
Donald:
Thanks so much for your reply. I was missing something very basic, but now
I "get it", as it were...
Thanks,
Mark Dzmura
> On Thu, 30 Mar 2000, Mark Dzmura wrote:
>
> > Hi:
> >
> > I am trying to do multiple layers of stylesheet-drive XSL
> > transformations to a single .xml file. (Presently, the number of
> > transformations is two, but it will grow for some purposes...)
> >
> > In addition, I have written a simple processor to dynamically add some
> > stuff into the Document. (In fact, this part is working and doing
> > exactly what I expect it to do...)
> >
> > To summarize, I want to first run my processor, then apply two levels
> > of XSL transformation, then format for web presentation. (Of course,
> > I could just use a single level of transformation and one .xsl file,
> > but that would defeat my purpose of separating the development and
> > maintenance of the different transformations... something which Cocoon
> > should help me to do!!)
> >
> > Continuing on, at first I thought I could simple-mindedly do something
> > like this in the .xml files:
> >
> > ----------
> >
> > <?cocoon-process type="nav"?> // my processor - this works
> >
> > <?cocoon-process type="xslt"?>
> > <?xml-stylesheet href="http://foobar.net/digipath/dphome.xsl" type="text/xsl"?>
> >
> > <?cocoon-process type="xslt"?>
> > <?xml-stylesheet href="http://foobar.net/digipath/dpframe.xsl" type="text/xsl"?>
> >
> > // formatter is the default
> >
> > ----------
> >
> > Although the individual stylesheets are verified to work, the
> > combination did not do what I expected... So I went to the Cocoon
> > sources.
> >
> > What I seemed to find there is that any attempt to execute a Processor
> > with a given MIME type and web browser type is always going to be
> > associated with the first matching stylesheet!! In essence, the
> > "dphome.xsl" stylesheet would be applied for both transformations...
> > Is this correct, or am I missing something??
> >
> > If so, I am trying to think of a way to eliminate this problem... An
> > obvious candidate is to remove the <?xml-stylesheet> node after
> > encountering it, so that it will not be selected the next time
> > through... this is already done with
> >
> > However, how does this interact with the caching store?? If the store
> > caches Documents, then it would have to maintain unmodified, virginal
> > copies and make a fresh copy for each pass through the Engine...
> >
> > Does anybody have any ideas?? Or am I going about this the wrong way
> > ??
>
> Sure. First of all, the first stylesheet must either create or copy the
> <?cocoon-process type="xslt"?> PI for the second transformation. Second of
> all, it must ensure that the first <?xml-stylesheet?> PI in the result
> document refers to the second stylesheet - personally, when I do this, I
> have my first stylesheet transform special tags like this:
>
> <myprefix:stylesheet href="foo.xsl"/>
>
> into
>
> <?xml-stylesheet type="text/xsl" href="foo.xsl"?>
>
> and drop the original xml-stylesheet PI, of course.
>
> - donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
)))) This email routed via a wireless gateway!! ((((
Re: multiple layers of XSLT ...
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 30 Mar 2000, Mark Dzmura wrote:
> Hi:
>
> I am trying to do multiple layers of stylesheet-drive XSL
> transformations to a single .xml file. (Presently, the number of
> transformations is two, but it will grow for some purposes...)
>
> In addition, I have written a simple processor to dynamically add some
> stuff into the Document. (In fact, this part is working and doing
> exactly what I expect it to do...)
>
> To summarize, I want to first run my processor, then apply two levels
> of XSL transformation, then format for web presentation. (Of course,
> I could just use a single level of transformation and one .xsl file,
> but that would defeat my purpose of separating the development and
> maintenance of the different transformations... something which Cocoon
> should help me to do!!)
>
> Continuing on, at first I thought I could simple-mindedly do something
> like this in the .xml files:
>
> ----------
>
> <?cocoon-process type="nav"?> // my processor - this works
>
> <?cocoon-process type="xslt"?>
> <?xml-stylesheet href="http://foobar.net/digipath/dphome.xsl" type="text/xsl"?>
>
> <?cocoon-process type="xslt"?>
> <?xml-stylesheet href="http://foobar.net/digipath/dpframe.xsl" type="text/xsl"?>
>
> // formatter is the default
>
> ----------
>
> Although the individual stylesheets are verified to work, the
> combination did not do what I expected... So I went to the Cocoon
> sources.
>
> What I seemed to find there is that any attempt to execute a Processor
> with a given MIME type and web browser type is always going to be
> associated with the first matching stylesheet!! In essence, the
> "dphome.xsl" stylesheet would be applied for both transformations...
> Is this correct, or am I missing something??
>
> If so, I am trying to think of a way to eliminate this problem... An
> obvious candidate is to remove the <?xml-stylesheet> node after
> encountering it, so that it will not be selected the next time
> through... this is already done with
>
> However, how does this interact with the caching store?? If the store
> caches Documents, then it would have to maintain unmodified, virginal
> copies and make a fresh copy for each pass through the Engine...
>
> Does anybody have any ideas?? Or am I going about this the wrong way
> ??
Sure. First of all, the first stylesheet must either create or copy the
<?cocoon-process type="xslt"?> PI for the second transformation. Second of
all, it must ensure that the first <?xml-stylesheet?> PI in the result
document refers to the second stylesheet - personally, when I do this, I
have my first stylesheet transform special tags like this:
<myprefix:stylesheet href="foo.xsl"/>
into
<?xml-stylesheet type="text/xsl" href="foo.xsl"?>
and drop the original xml-stylesheet PI, of course.
- donald