What part of the JSP needs to be dynamic? I can see you needing HTML and anything else client related dynamic, but not the JSP scriplet code itself. Doing this means each page would have to be compiled every time into a new servlet. Are you trying to created a web site or a JSP code generator? I would think all the logic that would be 'dynamic' could be developed as methods in a bean and then the parameters would make the processing and result dynamic.
-----Original Message----- From: Brian J. Sletten [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 21, 2002 11:46 AM To: [EMAIL PROTECTED] Subject: Any better ideas? 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
