[jira] Reopened: (STR-479) make "action" attribute of html:form tag optional w/default = URL launching it

["David Evans (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/STR-479?page=all ]
     
David Evans reopened STR-479:
-----------------------------


> make "action" attribute of html:form tag optional w/default = URL launching it
> ------------------------------------------------------------------------------
>
>          Key: STR-479
>          URL: http://issues.apache.org/struts/browse/STR-479
>      Project: Struts Action 1
>         Type: Improvement

>   Components: Taglibs
>     Versions: Nightly Build
>  Environment: Operating System: All
> Platform: All
>     Reporter: Jeff Skubick
>     Assignee: Ted Husted
>     Priority: Minor
>      Fix For: 1.3.0
>  Attachments: patch_ActionServlet.java, patch_ActionServlet_1-94.java, patch_FormTag.java, patch_FormTag_1-18.java
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira