Hi,

I'm having a problem with a combination of modules, tiles and html:form. Hopefully someone out there has a better solution than what I've come up with.

The short version of my saga is that html:form in a jsp included as a tile by an action of a sub-application cannot resolve it's 'action' attribute into the appropriate action defined in the sub-application's struts config file.

The long version of the saga... (and there's a URL to a tarball of an example of my problem at the bottom)

My web.xml specifies two struts configuration files:
   <init-param>
     <param-name>config</param-name>
     <param-value>/WEB-INF/struts-config.xml</param-value>
   </init-param>
   <init-param>
     <param-name>config/admin</param-name>
     <param-value>/WEB-INF/struts-config-admin.xml</param-value>
   </init-param>

Each of the named config files installs the Tiles plugin. struts-config.xml looks to tiles-definitions.xml while struts-config-admin.xml looks both there and at tiles-definitions-admin.xml.

In struts-config-admin.xml I have the following action defined:
   <action path="/broken1"
           type="org.apache.struts.tiles.actions.NoOpAction"
           >
     <forward name="success" path="tile.broken1"/>
   </action>
This, of course, corresponds to the context-relative url /admin/broken1.do.

The tile definition for 'tile.broken1' in tiles-definitions-admin.xml is:
 <definition name="tile.broken1" extends="layout">
     <put name="body" value="/WEB-INF/jsp/admin/broken1.jsp"/>
 </definition>

Finally, the 'layout' tile is defined in tiles-definitions.xml as:
 <definition name="layout" path="/WEB-INF/jsp/layout.jsp">
   <put name="title"   value="Struts Issues" />
   <put name="header"  value="/header.do" />
   <put name="footer"  value="/footer.do"/>
   <put name="body"    value="/WEB-INF/jsp/blank.jsp" />
 </definition>

broken1.jsp attempts to create a trivial form thusly:
<html:form action="/admin/bar.do">
 <html:text property="name"/>
</html:form>

So, with all of that in place, when i try to access http://localhost:8080/StrutsIssue/admin/broken1.do (using JBoss 3.0.6 by the way) I get a nasty stacktrace telling me:
[ServletException in:/WEB-INF/jsp/admin/broken1.jsp] Cannot retrieve mapping for action /admin/bar' javax.servlet.jsp.JspException: Cannot retrieve mapping for action /admin/bar at org.apache.struts.taglib.html.FormTag.lookup(FormTag.java:729) at org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:501) at org.apache.jsp.broken1$jsp._jspService(broken1$jsp.java:72)
etc...


Thinking that, perhaps, the jsp thinks it is within the /admin "scope" (if you'll pardon the misuse of the term), I try again with:
<html:form action="/bar.do">
<html:text property="name"/>
</html:form>
But, as expected, that fails because there is no /bar action defined in the struts-config.xml (only in struts-config-admin.xml)


I have a workaround but I don't like it very much. First we return to struts-config-admin.xml with a new pair of actions:
<action path="/working"
type="org.apache.struts.tiles.actions.NoOpAction"
>
<forward name="success" path="tile.working"/>
</action>
<action path="/workingView"
type="org.apache.struts.tiles.actions.NoOpAction"
>
<forward name="success" contextRelative="true" path="/WEB-INF/jsp/admin/working.jsp"/>
</action>
I don't like this for two reasons:
1) I have to define two action paths for every action
2) I now have an action path that directly forwards to a jsp rather than handling all of that with tiles


tiles-definitions-admin.xml picks up the new tile.working definition so that the defined layout will be pleased:
<definition name="tile.working" extends="layout">
<put name="body" value="/admin/workingView.do"/>
</definition>
I don't like this because now my tiles have knowlege of the sub-application's context. Ideally, the '/admin' partial-path should only be known to web.xml.


And the working.jsp is:
<html:form action="/bar.do">
<html:text property="name"/>
</html:form>
The only thing I really like about the solution is that the working.jsp references the action path within the scope of the /admin module.


I'm using struts 1.1-RC1 BTW.

A simplified and fully working example of my problem is here:
   http://www.tragus.org/~jcej/StrutsProblem.tgz
There's a deployable warfile in the target subdirectory of the tarball.

Thanks,
J


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to