Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
Nightly Build
-
None
-
Operating System: All
Platform: All
-
6686
Description
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.