Form submit - validate - display error message - cycle -> what is the recommended way to implement this?

[Alexander Zimmer <al...@unycom.com>]

Hi there,

 

I seem to be not able to find documentation about a recommended way to
do a request-validation-cycle like it is common in webapplication
programming.

 

I tried this to do a page with some edit elements, imagine a template
"ChangeValues.vm" which shows the data with a HTML form containing edit
elements, and a template "ShowValues.vm" which shows the same page in
read-only state (this page should be displayed after successful form
submission).

 

HTML-Form on "ChangeValues.vm" -(submit)--> Action class --> form
validation in some doXXX method which is:

*** in Action class, Method doXXX: ****

  - if validation fails --> set error message into Velocity Context

  - if validation succeeds --> setScreen('ShowValues.vm')

 

*** in Screen class "ChangeValues.java": ****

fetch data from DB (via Torque classes)

 

 

 

So, as you can see, I will display the ChangeValues.vm which just
displays the current data (retrieved from the database using Torque) in
editable state.

In case of form submit the Action method doXXX is fired before the
screen class ChangeValues is called. Thus, the form data is validated
and if it fails, an error message is put into to the context and the
action ends. Following this, the screen class is being executed by the
page - so the Velocity template in turn places the error message on the
screen. Looks fine (not really, wait a minute).

 

On the other hand, if validation succeeds, the instruction
rundata.setScreen("Afterchange.vm") will (sort of) redirect to the next
Screen. Looks fine, too (not really).

 

 

But - I have 2 points which I deem not good:

 

1. on successful validation the post-page that I "redirect to"
("ShowValues.vm") can not be refreshed as this would lead to the form
data be posted once again. This is not good.

In contrast, the standard way of implementing a WWW form is IMHO: after
successful validation, perform a HTTP redirect, so that the following
page "forget" about being in an editable state right before. This page
can be refreshed without side effects. How is this supported in Turbine?

 

 

2. on failed validation, my version of the submit cycle displays not the
enterered values along with the error message, but instead the error
message and the unchanged values from the database, because AFTER the
action (which validates the form data) the screen class retrieves the
values from the database, where the not-yet-validated values are not
persisted yet. This is REALLY not good.

 

Instinctively, I would depict a submit cycle like this:

 

  a) the class responsible for providing the data to display (page
class??) retrieves the current values from the database

  b) the Action class overwrites some these model data with data from
the HTML form submission

  c) the Screen class displays the model data

 

Thus, the HTML form data will be displayed, regardless whether they are
already validated and persisted in the database or not.

 

So it all boils down to the central question: is there a recommended and
proven way to do this common form handling cycle? How is this solved in
the existing projects using Turbine/Torque? I think an example (if not
yet existing) or a schematic illustration would prove to be very useful
for Turbine newvbies (like me) as it illustrates very much the ideas of
the Turbine components.

 

TIA

Alex

 

PS: I try to do this without using the Intake service because I do not
want to impose another layer of complexity on a simple challenge

RE: Form submit - validate - display error message - cycle -> what is the recommended way to implement this?

[Declan Shanaghy <tu...@shanaghy.com>]

You are right, this sort of stuff would be good to have documented.
I had similar questions when i first started using turbine and 
ended up developing my own pattern.

If people agree with my pattern I'll volunteer myself to write these docs.


I have found it helpful to extend all my actions from my own base class
which has the following methods:


/*
*	Pulls form data from the request and validates it.
*	Forms which fail validatation cause an exception to be thrown.
*/
protected Group setupIntakeGroup(RunData data, Context context, FormIFC
form)throws IntakeException


/*
*	Removes a group from the context.
*/
protected void removeIntakeGroup(Context context, Group group)


/*
*	Validates all fields in a group.
*	Fields which fail validatation cause a message to be added to the
rundata object
*/
private void validateFields(RunData data, Group group) throws
IntakeException


In my derived action classes i can now simply do this

AddressBean addressForm = new AddressBean();
Group addrGroup = setupIntakeGroup(data, context, addressForm);

//...do stuff....

removeIntakeGroup(context, addrGroup);

Removing the group is not required, its only necessary if you go back to the
same screen
and you dont want the entered data to be displayed again.

To furhter simplify the process i also use a macro to display my submit
buttons which
adds a hidden form input denoting the current page. With this i can catch
validation 
exceptions in the base class and redirect back to whatever page the user was
on.


It is a generic solution however the implementation i have right 
now is not completely generic.


if you have more questions I'll be glad to help out further
including sending code, 


Anyway on to some answers...

A1:
runData.setRedirectURI(XXX);
runData.setStatusCode(302);


A2:
After failing validation you can put the data objects back into the context
When the screen class executes it can check for existence of data in the
context.
If data exists it poopulates the response with that data, otherwise it loads
from the DB.

I use a class called FormTool to do this kindof stuff for me.
Here's an example from an address update page

#if ( !$addressForm)
    #set ($addressForm = $forms.getBillingAddressForm($memberId))
#end

	
 

-----Original Message-----
From: Alexander Zimmer [mailto:alexander.zimmer@unycom.com] 
Sent: Wednesday, October 31, 2007 1:27 AM
To: user@turbine.apache.org
Subject: Form submit - validate - display error message - cycle -> what is
the recommended way to implement this?

Hi there,

 

I seem to be not able to find documentation about a recommended way to
do a request-validation-cycle like it is common in webapplication
programming.

 

I tried this to do a page with some edit elements, imagine a template
"ChangeValues.vm" which shows the data with a HTML form containing edit
elements, and a template "ShowValues.vm" which shows the same page in
read-only state (this page should be displayed after successful form
submission).

 

HTML-Form on "ChangeValues.vm" -(submit)--> Action class --> form
validation in some doXXX method which is:

*** in Action class, Method doXXX: ****

  - if validation fails --> set error message into Velocity Context

  - if validation succeeds --> setScreen('ShowValues.vm')

 

*** in Screen class "ChangeValues.java": ****

fetch data from DB (via Torque classes)

 

 

 

So, as you can see, I will display the ChangeValues.vm which just
displays the current data (retrieved from the database using Torque) in
editable state.

In case of form submit the Action method doXXX is fired before the
screen class ChangeValues is called. Thus, the form data is validated
and if it fails, an error message is put into to the context and the
action ends. Following this, the screen class is being executed by the
page - so the Velocity template in turn places the error message on the
screen. Looks fine (not really, wait a minute).

 

On the other hand, if validation succeeds, the instruction
rundata.setScreen("Afterchange.vm") will (sort of) redirect to the next
Screen. Looks fine, too (not really).

 

 

But - I have 2 points which I deem not good:

 

1. on successful validation the post-page that I "redirect to"
("ShowValues.vm") can not be refreshed as this would lead to the form
data be posted once again. This is not good.

In contrast, the standard way of implementing a WWW form is IMHO: after
successful validation, perform a HTTP redirect, so that the following
page "forget" about being in an editable state right before. This page
can be refreshed without side effects. How is this supported in Turbine?

 

 

2. on failed validation, my version of the submit cycle displays not the
enterered values along with the error message, but instead the error
message and the unchanged values from the database, because AFTER the
action (which validates the form data) the screen class retrieves the
values from the database, where the not-yet-validated values are not
persisted yet. This is REALLY not good.

 

Instinctively, I would depict a submit cycle like this:

 

  a) the class responsible for providing the data to display (page
class??) retrieves the current values from the database

  b) the Action class overwrites some these model data with data from
the HTML form submission

  c) the Screen class displays the model data

 

Thus, the HTML form data will be displayed, regardless whether they are
already validated and persisted in the database or not.

 

So it all boils down to the central question: is there a recommended and
proven way to do this common form handling cycle? How is this solved in
the existing projects using Turbine/Torque? I think an example (if not
yet existing) or a schematic illustration would prove to be very useful
for Turbine newvbies (like me) as it illustrates very much the ideas of
the Turbine components.

 

TIA

Alex

 

PS: I try to do this without using the Intake service because I do not
want to impose another layer of complexity on a simple challenge



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@turbine.apache.org
For additional commands, e-mail: user-help@turbine.apache.org