struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 7202] - Add forward attribute to FormTag to allow submision to a global forward
Date Thu, 04 Jul 2002 02:38:27 GMT
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 craig.mcclanahan@sun.com  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:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message