DO NOT REPLY [Bug 34750] New: - Provide better support for dialogs; avoid POSTDATA situations

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34750>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34750

           Summary: Provide better support for dialogs; avoid POSTDATA
                    situations
           Product: Struts
           Version: Unknown
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Controller
        AssignedTo: dev@struts.apache.org
        ReportedBy: jmikus@gmail.com
 BugsThisDependsOn: 30292


Comparing to other frameworks, Struts does not contain enough ready-to-use UI
components. Most developers use standard Action or at best DispatchAction
classes. Many applications respond with result page immediately to POST request,
generating dreaded "Do you want to resend POSTDATA?" dialog and double submit
sitiation.

Proposed DialogAction allows to create clean user interface with following features:
* Input/output separation -- data is inputted using only POST request method,
page is rendered using only GET request method.
* Automatic reloading of the dialog page if error detected
* Using redirection between POST and GET, which eliminates POSTDATA problem and
allows to browse easily back and forward
* Semi-automatic message handling: programmer has to stick messages into session
in the handler method, and RequestProcessor will remove them automatically
* Less coding and much improved user experience overall
* DialogAction, based on DispatchAction, brings Struts closer to rival
frameworks with event-driven architecture, still keeping best features of front
controller paradigm.

See javadoc to this class for usage example.

This action requires from a developer to use several strict rules, which may be
considered too restrictive, and the whole use case may be considered too
limited. But in reality dialog use case comprises at least half of all action
class uses. I am sure this class (or another version of the same idea) will be
used a lot. Before rejecting this enhancement, please take into account that
Ruby on Rails has this kind of request/response processing as standard. Spring
MVC uses it too, as well as JSF. This is simply less error-prone and more
user-friendly.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org