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=6686>. 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=6686 make "action" attribute of html:form tag optional w/default = URL launching it Summary: make "action" attribute of html:form tag optional w/default = URL launching it Product: Struts Version: Nightly Build Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Proposal: The "action" attribute of the html:form tag should be made optional. If absent, Struts should use whatever URL triggered the rendering of the JSP page in the first place as the form's "action" attribute. Example: A form is submitted to http://my.domain.com/someaction.do Ultimately, Struts renders page_with_form.jsp in response and sends it to the browser. page_with_form.jsp contains a html:form tag with no "action" attribute, so Struts renders the form with action="/someaction.do" the default action is taken to be the absolute URL, sans FQDN and port number (since the browser will take care of that detail on its own) Rationale: This behavior can be achieved by having an Action class set a page-context attribute with the value of its trigger (say, "/someaction.do"), then using it as a scripting variable within the html:form tag, but it's logically cleaner to simply have the html:form tag point to "itself" (the action that launched it in the first place) when no action is explicitly specified. One specific -- and common -- use for this would be the creation of a login form for a site where users are allowed to roam freely and anonymously until they decide to do something with consequences, at which point they'd be required to log on before the action they initiated is completed. By creating an abstract login form bean class, extending it with every other form bean class used by the site (so all the form beans have the latent capability of acting as a login form bean themselves), creating an abstract Action class that attempts to log in users whenever a username/password was submitted, verifying that the user is (now) logged on, and either returning the mapping to the common login form jsp or calling an abstract method that gets extended by Actions for logged-in users, it becomes possible to transparently and seamlessly handle logins the moment it becomes necessary without interfering with the user's workflow (the moment he successfully logs in, the task he originally launched completes as though the login interruption never occurred). The catch is, of course, that a login form that can be displayed in response to just about any mapped action needs to be able to submit itself to the same action that called it. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
