struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Métras <gen...@sympatico.ca>
Subject Re: Request to reserve two hidden field names
Date Tue, 03 Oct 2000 17:10:54 GMT
Taylor wote:

> Just glancing at the example application bundled with struts I found this:
>
> <struts:hidden property="action"/>
>
> In other cases the "action" is sent as a request parameter in the URL.
> So even the example of how to use struts, which is basically all newbies
> have to go on, uses a hidden field to pass info back to the servlet.  Just
> simply having two instance variables 'cmd' and 'token' doesn't solve the
> problem of informing server side objects about which button or link the
user
> selected.

Let's sort when it's more natural to use hidden fields against class
variables.

Hidden field:
* You want to be able to see the value stored in the field (use your browser
to show the source), for instance for debug (but in that case, it's safer to
write a special page to show all the session attributes...).
* You want to send the content of the field with the other fields of a form.
This is justified if you use graphical buttons instead of the classical
Submit and Cancel. You need to fill the field in JavaScript before
submitting the page.
* You're an ol' HTML chap, and you still think that mixed <TABLE> and <FONT>
tags are better than style sheets. And you can remind that your first HTML
form already had hidden fields...;-)
* You are managing the state of your form on the client side, with
JavaScript.
* In a GET action, because Struts uses logical forwards, it's simpler to put
URL parameters in a field than to append parameters to the links.

Class attribute:
* You need to keep the state of the form in a multiple state form. That way,
you can disable the [Back] button of the browser.
* You want to freeze a common behaviour in a Java class instead of spreading
fields in all your forms.
* You don't want to use a <FORM>?


In fact, generally, the two approaches are complementary. For instance, in a
form with two select boxes (to chose a car and a color), we could have the
following state graph:

    Init --->
        Select a car ---->
            Select a color ---->
                Display the reference number

You use a class attribute to store the static state of the form, and an
hidden "action" field to store the dynamic action of the user in the form
(select an item in one or the other select box).

Open the form
    state="Init"
The user selects a car model in the first select box (action="select1")
    state="CarSelected"
The user selects a color for the car (action="select2")
    state="ColorSelected"
Display the reference
    state="DisplayReference"

You can decide that you don't allow the user to change the car selected but
only the color, or reinit the color tables when he changes the car... Of
course, this sends a request to the server to update the state of the form.
This kind of model is also used with "wizard style" forms.

The action hidden field is so commonly used that it could be integrated in
the ActionForm class, with the get/set functions.
The state field don't need to be presented to the user and should be
integrated in an ActionStateForm class, inheriting from ActionForm. There
would be a changeState(action) function that would be able to change the
state of the form, and then you could proceed to the validate() function.

Just a few ideas...

Pierre Métras


Mime
View raw message