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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
