DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7202 Add forward attribute to FormTag to allow submision to a global forward ------- Additional Comments From [EMAIL PROTECTED] 2002-07-04 02:38 ------- OK, I am *not* sold -- either by the original argument or Ted's discussion. It seems that Martin's motivation is to avoid encoding any of the context-relative mapping stuff into the "action" attribute. I would submit that we've already got that. Consider an <action path="/login" .../> that declares your login action. All you need to put in the form is: <html:form action="/login"> and everything else is automatic -- context path prefixing, subapp prefixing, and even the formatting for whether you are using extension mapping or path mapping. Everything is clean and simple, and easy to understand -- the "action" attribute of a form maps directly to an <action> element in struts-config.xml. How the application decides to implement that action is totally hidden from the page developer, as it should be. Regarding Ted's use cases: (1) Page developers already have a single namespace for form submits. The proposal is to make them have to know about two of them. (2) This kind of reuse can easily be accomplished on the client side (Javascript that changes the destination) or on the server side (polymorphic receiving action that does the right thing). The existence of things like DispatchAction and LookupAction already illustrate that reuse is straightforward without this change. (3) I don't buy that "inputForward" (once implemented) would generally go back to an Action -- it's going to point back at the logical forward for the input page itself, like the "input" attribute today generally does. As I understand it, the proposal is to require page authors to become familiar with using two logical-physical mapping mechanisms for form submits, where they would have to get two related configuration settings right in order for things to work correctly. IMHO, this is counterproductive. Bottom line -- *I* am not going to apply this patch, because I think it is a bad idea. But I'm not the only committer around here. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
