Any better ideas?

["Brian J. Sletten" <bs...@nova.org>]

I asked previously if anyone had any suggestions about dealing with 
multi-step JSP compilation and didn't get any responses. I came across 
a concrete example that might generate more discussion.

I'm working on a prototype web application that is very dynamic and 
generates JSPs on the fly from XML and XSLT files. One of the 
problems I face is that when I generate links in the XSLT, I don't have 
access to the ContextPath and Struts doesn't get involved at that level.

So, in a.jsp, I'll have:

<c:import url="/xml/address.xsl" var="currentTransform"/>
<x:transform xml="${userKey}" xsl="${currentTransform}"/>

That will do the transformation and spit out HTML. The problem is that I 
occasionally try to spit out other JSP directives, taglibs, etc. from XSLT 
tranformation. These never get evaluated since the transformation 
definition happens as part of compiling the original JSP. I realize that I 
can move the XSLT into an Action that will spit out the JSP, but I think 
this would be a very convenient thing to do at times from within a JSP, 
particularly for fast prototypes.

The concrete example is in generating links from within the XSLT. I have 
a template called createHREF to generate context-sensitive, well-
formed URLs. It is in a util.xsl that is included by any XSLT file that 
needs it. Up until now, I've just been using a variable in util.xsl that 
specifies the baseURL from which to build all other ones.

I thought, "Hey, if I changed that to use <%= request.getContextPath() 
%> I can get away without the variable". Of course, that didn't work 
because of the problem mentioned above.

For now, the best solution I can come up with is to use an <x:param> in 
the <x:transform> tags that is populated with the <%= request...%> call. 
It should work, but it is much more labor intensive than I'd like as I need 
to include it as a param to any transformation that might want to 
generate links. The good news is that the global param only need be 
defined in the outer XSL file and the included inner XSL file can still 
reference it.

But, global variables weren't A Good Thing[tm] in C and they aren't here 
either.

Does anyone have any thoughts about this in the general case 
(generating stuff that needs to be compiled via <x:transform>) or this 
specific case of propagating context in a simpler way?

TIA,

Brian

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Any better ideas?

[James Strachan <ja...@yahoo.co.uk>]

From: "James Strachan" <ja...@yahoo.co.uk>
> Agreed - I've had this thought too. The only real issue is the current
JAXP
> API for XSLT requires that all variables be pushed into XSLT - XSLT is not
> capable of pulling the variables depending on the contents of the
> stylesheet. So the only way, until JAXP changes, is via
>
> <x:transform...>
>     <x:param name="foo" value="${something."/>
> </x:tranform>

Another way could be that when Transformer objects are created, all
available JSP scoped variables could be fired into the Transformer using the
setParameter() method before its used, just in case they are referred to by
the stylesheet. Though this is an inefficient solution to the problem; it'd
be far better for the stylesheet to pull what variables it needs, on
demand,.

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Any better ideas?

[James Strachan <ja...@yahoo.co.uk>]

----- Original Message -----
From: "Shawn Bayern" <ba...@essentially.net>
> It seems that there are really two separate issues:  you're discussing (a)
> a JSP preprocessor (as you later described) and (b) an XSLT engine aware
> of the PageContext.  The idea of a preprocessor is somewhat general but
> probably not needed by too many people.  However, the latter idea is
> something that I've had in the back of my mind; it might be appropriate in
> a future version of JSTL to allow the XPath variables that make up the
> XPath evaluative context in JSTL tags to apply also to XSLT
> transformations conducted through <x:transform>.  At least, it's probably
> worth exploring.

Agreed - I've had this thought too. The only real issue is the current JAXP
API for XSLT requires that all variables be pushed into XSLT - XSLT is not
capable of pulling the variables depending on the contents of the
stylesheet. So the only way, until JAXP changes, is via

<x:transform...>
    <x:param name="foo" value="${something."/>
</x:tranform>

If JAXP introduced some kind of VariableScope interface that could be set on
a Transformer to resolve variables, it'd be easy to expose JSP scopes into
an XSLT engine without unecessary manual plumbing like the above use of
<x:param/>. Stylesheets could just pull in variables as and when they are
needed..

public interface VariableContext {
    public Object getVariableValue( String uri, String localName );
}

The above is pretty much what VariableContext looks like in Jaxen

http://jaxen.org/
http://jaxen.org/apidocs/org/jaxen/VariableContext.html


I've submitted the above proposal to the JAXP EG but as usual, when you're
not on an EG you never hear anything more about it ;-)

James


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Any better ideas?

["Brian J. Sletten" <bs...@nova.org>]

> it might be appropriate in a future version of JSTL to allow the XPath 
> variables that make up the XPath evaluative context in JSTL tags to 
> apply also to XSLT transformations conducted through <x:transform>.
>  At least, it's probably worth exploring.
I think that is a fantastic idea.

Now that the standard is standard, it's time to change it! ;)



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Any better ideas?

[Shawn Bayern <ba...@essentially.net>]

On Tue, 21 May 2002, Brian J. Sletten wrote:

> I asked previously if anyone had any suggestions about dealing with 
> multi-step JSP compilation and didn't get any responses. I came across 
> a concrete example that might generate more discussion.
> 
> I'm working on a prototype web application that is very dynamic and 
> generates JSPs on the fly from XML and XSLT files. One of the 
> problems I face is that when I generate links in the XSLT, I don't have 
> access to the ContextPath and Struts doesn't get involved at that level.

It seems that there are really two separate issues:  you're discussing (a)
a JSP preprocessor (as you later described) and (b) an XSLT engine aware
of the PageContext.  The idea of a preprocessor is somewhat general but
probably not needed by too many people.  However, the latter idea is
something that I've had in the back of my mind; it might be appropriate in
a future version of JSTL to allow the XPath variables that make up the
XPath evaluative context in JSTL tags to apply also to XSLT
transformations conducted through <x:transform>.  At least, it's probably
worth exploring.

-- 
Shawn Bayern
"JSP Standard Tag Library"   http://www.jstlbook.com
(coming this summer from Manning Publications)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>