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

Reply via email to