the only bit I haven't thought through is how do deal with forms contained inside tiles. I think
<put name="action" value="/foo.do" type="string" /> <put name="body" value="/tiles/mytile.jsp" type="page" />
then in the tile naturally
<tiles:useAttribute name="action">
<html-el:form action="${action}">I'll have a play some more.
But i certainly think that generating the mappings with xdoclet tags in scriptlets would be useful, even if it just just for the sake of having an example.
On 18 Feb 2004, at 17:08, Carl Walker wrote:
The glitch is that you have to work with the mappings. You can't freely type
JSP code into a directory without thinking about how its deployed. You'll
have to write scripts that compile your JSPs, probably JAR the JSPs, and
generate sections of your web.xml file and merge those sections in with the
static parts (taglibs, ActionServlet).
Precompiling the JSPs means that Tomcat will not have to fork off a javac.
This is important to us because the Solaris fork duplicates the image of the
parent Tomcat process (at over 200Mb) so a javac process to compile 500bytes
of JSP fragment creates a second 200Mb process. We ran out of swap space one
day and some of the application threw up a Jasper error. So, we now deploy
only precompiled webapps.
One note about the mappings...You should try to mimic what you have now. For
example, mywebapp/jspfrag.jspf should still access the same code whether you
are using a JSP or a precompiled JSP (a servlet). So, the url-pattern would
continue to read /tiles/FooTitle.jspf. This allows you to construct links
and test in a manner that isn't locked to a particular deployment. In
development, we work within the JSP directories so we want to compile these
as they change.
If you're still skeptical, remember that Tomcat does the same thing on-the-fly.
Mark Lowe wrote:
Umm
I like the sound of that. I haven't thought it through fully yet so there could be some glitch i've missed. just to complement the suggestion (other than having an ant task the fire everything up) you could have xdoclet comments to generate your web.xml
<% /** * * @web.servlet * name="FooTile" * display-name="FooTile" * description="My tile" * load-on-startup="3" * * @web.servlet-mapping * url-pattern="/tiles/FooTile" */ %>
Something still doesn't smell right though, tiles-defs? and maybe struts config? Perhaps have the a tile attribute in your definition of type page that calls the servlet mapping.
<put name="body" value="/tiles/FooTile" type="page" />
Okay.. so that theory seems okay. what about tiles with forms?
what about the form paths? and then mapping those in struts config to tiles defs (by way of forwards, assuming thats the way one would want to do things). and the additional problem of multiple forms on one page?
I'll ponder some more..
On 18 Feb 2004, at 15:47, Carl Walker wrote:
Compile the tiles into .java files, compile these files into .class
files
and jar them up. You'll need to add servlet mappings to every webapp's
web.xml, though.
Here's the test JSP I'm working with (called myjsp.jsp).
<%@ page session="false" %> <%@ page import="java.util.Date" %>
<html> <body> <h1>Hi, the date is <%= new Date() %></h1> </body> </html>
The directory structure I have is ./classes/ ./jsp/ ./jsp/myjsp.jsp ./src
The command to precompile the JSP $ jspc.sh -d src/com/yourpackage -p com.yourpackage -uriroot jsp -webxml web.xml jsp/myjsp.jsp
The directory structure is now ./classes ./jsp/myjsp.jsp ./src/com/yourpackage/myjsp_jsp.java
Then run this... $ $ javac -classpath $CATALINA_HOME/common/lib/servlet.jar:$CATALINA_HOME/common/lib/ jasper-runtime.jar \^J-d classes src/com/yourpackage/myjsp_jsp.java
"Raymaker, Dora" wrote:
Hello, I am wondering if tiles can be put in a jar so that they become
accessible to multiple struts applications. Any information would be
much appreciated!
Thanks,
Dora Raymaker
Sr. Technical Writer
XO Communications, Interactive Division
503.972.6808
[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
