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

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

(Tony, you happened to reply to me personally, therefore I'm including
your mail because your points seem very reasonable and interesting)


Thank you both, Tony and Declan for you ideas.

Pondering your (both) input, I like very much your idea of an
encapsulated object holding all data which is either captured from the
submitted form data or - if no form data have been posted - retrieved
from the model data (in my case, via Torque from the database).

So, the base class of such a form data storage would something like:

public abstract class FormData {

  /** populate with data from the HTTP request (submitted data) */
  public abstract void captureRequestParameters(RunData data);

  /** retrieve data from the business model */
  public abstract void retrieve();

  /** persists data into the business model */
  public abstract void save();

  /**
   * validate data, typically after capturing data from HTTP request
   * 
   * @return flag: true ... data ok; false ... validation error
   */
  public abstract boolean isValid();

  /** one-in-all method */
  public void doSubmitAction(RunData data) {

    this.captureRequestParameters(data);
    if (this.isValid()) {
      this.save();
    }
  }
}

For each editable HTML form I would derive a concrete class from
FormData holding the specific form data needed.

I think I got the basic points, thank you both for your detailed
responses.

Cheers,
Alex


-----Original Message -----
From: Tony Oslund [mailto:aoslund@bevcomm.net] 
Sent: Mittwoch, 31. Oktober 2007 21:16
To: Alexander Zimmer
Subject: Re: Form submit - validate - display error message - cycle ->
what is the recommended way to implement this?

I use just Turbine and Velocity, no Intake, etc.

...

Let's say I have a form test.vm

If I have a matching class test.java, I only use this to load/re-load
data 
required to populate the context for test.vm.  Though it is not required
(by 
anyone, or anything) I never perform business logic/updates within 
doBuildTemplate, I leave it up to my action classes (or classes that
they 
use).

If I have a matching class testAction.java, I use this to process the
events 
on the form.  If my form passess validation, I explicitly re-direct to
some 
next form and immediately return from the action (redirects do not
prevent 
the rest of the code within the event from executing). If validation
fails, 
I load up some error flag/mesg into the context and return from that
point 
in my method.  test.java would again re-load the data for this form, and
if 
necessary set a default error code (or non-error code) into the context
in 
case I got there without first hitting my action class.

I get the impression that you are possibly entering/validating data on a

sequence of forms.  In this case you can add an object to your session
data 
that allows you to track the state of your data entry process.  If the
user 
starts hopping forward and backward within their brower, you can put a
state 
test within test.java to re-direct to the appropriate form/state.  In my

case I usually have a test at the top of doBuildTemplate to handle this.

What you want to avoid are situations where the user can refresh the
form 
and trigger an unwanted event potentially duplicating data, etc.
Redirects 
work nicely for getting around this (don't include a reference to the
action 
within the redirect), also be careful what you put in doPerform.

Use Posts not Gets...

My action classes often have a doInitialize event which is only accessed

when re-directing from another form.  doInitialize can do a re-direct 
itself...

...

Within doBuildTemplate, you might wish to check to see if the data for
your 
form has already been initialized, if so then don't reload it.

To simplfy dataHandling (within test.java, testAction.java, etc) I do 
something like TestData testData = TestData.getData(data) wherever I
want to 
access the data for test.  I allow TestData to initialize/retrieve,
store, 
validate, etc any data for test (regardless of what technologies lie
below 
TestData).  TestData loads itself into the session if necessary, I can
test 
its state, see if it is already intialized, etc.  Personally, I have
found 
it a bad practice to embed data handling logic directly within 
doBuildTemplate.

If my session expires, then TestData is (by default) back to its
original 
state.

By the way, you may wish to tag your forms with some hidden data that 
timestamps them, etc.  This is a pretty easy way to prevent the user
from 
backing up and submitting data on an obsolete form.  Just allow TestData
to 
initialize/verify the timestamp.  There is a Turbine technology (if I 
remember correctly within RunData) for this, but I never found it to be
very 
effective.

I allow TestData to capture the form parameters.  I also dump a
reference to 
TestData itself into the context.  By encapsulating all of my form data 
(possibly for more than one form) into TestData, I don't have to
maintain a 
lot of unnecessary references to individual form data elements.  To add
new 
data elements I add them to TestData and to the necesary form.

...

I know that there are a lot of people building T/V apps using different 
technologies (which I have plenty of respect for), but I have been able
to 
build unbreakable web forms and very maintainable apps for the last half

dozen years using just Turbine and Velocity.  Usually without doing
anything 
more complex than the things that I have described here.

Best of luck.


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