Well I've read it now ;)
I see you've based the Action around the Post-Redirect-Get pattern. I
use it all the time. It's good.
I don't understand how you managed to get the page with validate-error
not to make an entry in the browser history. I see you've turned off
automatic validation but closer than that I'm not sure. It seems to be
linked to the no-cache stuff but I didn't think the caching had anything
to do with the browser history.
Adam
On 08/06/05 15:54 Michael Jouravlev wrote:
Adam, did you manage to read the full description DialogAction? ;-) I
know, I know, that the first paragraph is very generic, but that is
what the action does. Can you suggest some better wording?
I would appreciate if you tried the examples, especially the one
called Login Control.
I guess I should hide SelectAction in the shadows, because the real
deal is the DialogAction. On the other hand, I don't think that it
makes sense to create a whole project out of one action. I will submit
it as a patch in Bugzilla, and will hope that Struts committers find
this class worth including in main Struts library. Because that is
what I actually want, to share the joy ;-)
Michael.
On 6/8/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
Michael,
I too like Jack concentrated on SelectAction, purely because it was
first in the text.
Looking at your description of DialogAction, I read the first paragraph
about DialogAction and didn't feel it was worth reading further - having
read about SelectAction (on the basis of your name) I then read that
desc of DialogAction and came across some amazingly non-descriptive
stuff like "accepting input data, dispatching submit event to a
> > method, generating error messages and rendering a view" (hmm,
sounds like my hello world servlet)
And then I stopped reading :O
From looking further at the description, it does look interesting, but
hey, this is the internet - 4 seconds and I'm gone! ;)
On 08/06/05 07:08 Michael Jouravlev wrote:
You do understand that SelectAction is actually just a helper, and the
real story is DialogAction, do you? Have you seen the Login Control
example?
On 6/7/05, Dakota Jack <[EMAIL PROTECTED]> wrote:
SelectAction is really old news and is what all the apps that use
multiple select image buttons do only with a lot less bloating of the
code See http://www.michaelmcgrady.com/button/
On 6/7/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote:
Struts Dialogs is an extension of Struts actions that provides an
improved user experience along with event-based programming model.
Struts Dialogs currently consists of two action classes: SelectAction
and DialogAction.
------------
SelectAction
------------
SelectAction is an abstract Action that dispatches an HTTP form
submission event to a handler method.
The purpose of this class is processing submission of HTML forms.
Unlike DispatchAction and LookupDispatchAction, which correlate value
attribute of submit form element with handler method, SelectAction
uses name attribute. This allows to display a user-friendly caption on
a submit button. Also, it is possible to change button caption without
rebuilding the application.
------------
DialogAction
------------
DialogAction is an abstract Action that provides basic dialog
functions, like accepting input data, dispatching submit event to a
method, generating error messages and rendering a view. DialogAction
allows to create robust user inteface and provides simple event-based
programming model.
DialogAction incorporates several innovative design decisions not
previously used in Struts. Some of them are already implemented in
other frameworks, like Ruby on Rails or JSF. Other features are unique
to DialogAction.
The cornerstone concept of DialogAction is separation of input and
output processes. This solves several issues, related to HTML form
input, like double submit problem, annoying POSTDATA messages, bad
usability when Reload, Back and Forward buttons are used.
DialogAction defines three different modes of operation:
* action initialization prepares action for use with new set of data;
* user input process accepts input data, updates domain model,
generates error messages;
* view rendering process generates a result page.
Separation of input and output improves usability and user experience:
* Any page can be reloaded without resending input information to
the server.
* As a consequence, an application does not have to cope with
double submits.
* Another consequence is that a user does not see "Do you want to
resend POSTDATA?" message.
* Using Back and Forward buttons is safe, because only result
pages are browsed.
-------------------------
Documents, files, samples
-------------------------
Online samples:
http://www.superinterface.com/strutsdialog
Documentataion:
http://wiki.java.net/bin/view/Projects/StrutsDialogs
If you cannot see pictures on SelectAction and DialogAction pages,
you might need to register and login to java.net. But it should
work without logging in.
Source code for DialogAction and amples is located at:
Folder:
https://easywizard.dev.java.net/servlets/ProjectDocumentList?folderID=3494&expandFolder=3494&folderID=3494
File name:
strutsdialog.zip
Michael Jouravlev.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
