URIResolvers base parameter with xsltc and cascaded imports 2006-08-14 - By Timothy Jones
My initial feeling is that the person who designed the method signature
for URIResolver.resolve() felt that base and current would have been
sufficient (and for only two levels, it is!) Stated another way, you
are a trailblazer for constructing a dependency tree of three levels.
tlj
-----Original Message-----
From: Holger Dehnhardt [mailto:dehnhardt@(protected)]
Sent: Monday, August 14, 2006 11:00 AM
To: xalan-j-users@(protected)
Subject: Re: URIResolvers base parameter with xsltc and cascaded imports
Hey Timothy, (and "Guten Abend";-)
first - thanks for the proper restatement!
The tip with the pop/pushStylesheet methods may be useful. I will wait,
if
Yash can give me further information but then it might be possible to
implement a callback in these methods and keep track of the 'stacklevel'
in
my URI-Resolver.
But first, I would be happy to know, if the current behaviour is
expected or a
bug.
Holger
Am Montag, 14. August 2006 16:36 schrieb Timothy Jones:
> Guten Tag, Holger!
>
> In my app, I have implemented a short URIResolver anonymous class that
> decides, depending on a configuration variable, to open xsl:include'd
> stylesheets from either Class.getResourceAsStream or
> URLConnection.getOutputStream.
>
> But in my application, I have one central stylesheet that is included
> from many others, but it is only one level deep. That is why I
didn't
> reply the first time you posted.
>
> The processor is obviously keeping a proper stack somewhere inside,
but
> the difficulty seems to be that from within the URIResolver interface,
> you are only given access to the base (bottom of the stack) and the
> current (the top of the stack). With only two levels of inclusion,
this
> is sufficient, but with three or more levels, you cannot see the
middle
> elements. Is this a decent restatement of the problem?
>
> I can see where it would be nice to have access to the stack that
> org.apache.xalan.processor.ProcessorInclude.startElement has access to
> (StylesheetHandler.popStylesheet() and pushStylesheet()), but I have
no
> idea if this is even a good direction to go towards, let alone the
best
> way to expose it (and of course, changing a public interface like
> URIResolver would be pretty disruptive).
>
> I wish this post were more helpful. But I am just an xalan user, too,
> not a developer.
>
>
>
>
> tlj
> -----Original Message-----
> From: Holger Dehnhardt [mailto:dehnhardt@(protected)]
> Sent: Monday, August 14, 2006 9:29 AM
> To: xalan-j-users@(protected)
> Subject: Re: URIResolvers base parameter with xsltc and cascaded
imports
>
> Hello!
> Sorry for asking again, but I really need some advice with the problem
> described below.
> Is anyone here who has written an URIResolver or can help in any way,
or
>
> should I ask on the developers list?
>
> Thanks Holger
>
> Am Montag, 24. Juli 2006 17:26 schrieb Holger Dehnhardt:
> > Hello,
> >
> > I'm trying to write my own URIResolver to keep track of changes in
>
> imported
>
> > stylesheets when compiling the main stylesheet.
> > Lets have this layout
> >
> > 1) http://localhost/main.xsl includes layouts/heads.xsl
> > 2) heads.xsl includes ../helpers/someFunctions.xsl
> > 3) http://localhost/main.xsl includes layouts/footers.xsl
> >
> > The interface method "resolve" in my uri-resolver is called three
>
> times
>
> > with the following parameters:
> >
> > 1) href=layouts/heads.xsl base=http://localhost/main.xsl
> > 2) href=../helpers/someFunctions.xsl base=http://localhost/main.xsl
> > 3) href=layouts/footers.xsl base=http://localhost/main.xsl
> >
> > even if the file is included from another stylesheet like 2), the
base
>
> does
>
> > not change.
> > Storing the base is no solution,
> > in 1) the base would be http://localhost/layouts/heads.xsl
> > but in 2) it would be http://localhost/helpers/someFunctions.xsl
> > and 3) would fail.
> >
> > Is this expected behaviour and if so, how can I manually keep track
of
>
> the
>
> > base?
> >
> > Thanks Holger
|
|
