Thanks. In that same thread there was another post describing what I was talking about: using a separate run mode to process data. IE. "edit" and "edit_proc".

I think the simple answer is that "it depends"!

I've usually processed everything related to one mode in its own handler, testing for the value of submit parameter to determine whether I need to process the form, or merely display it.

The reason that I tend to use this approach is that it lets me show errors to the user in a simple manner.

Take for example the example of a form that asks for a name and an email address.

In my HTML::Template page I will have the entry fields for the input of the values, and I will also have some stubs for error messages "You must enter an email address", etc.

This way if there is an error I can re-display the input page with the users values entered into it, and the relevent error message.

The alternative approach would be to have the handling mode have the template it was going to display and an error template - and I didn't want to have two templates which might get out of sync.

I generally take the approach that each run mode should do one thing. How you determine the granularity of the 'one thing' is up to you, but by and large I tend to define my 'one thing' is 'what do i need to do to get the user to the next screen?'. So, most of any given run mode I code is geared towards retrieving/manipulating/authenticating data to feed to the template i want to serve to the user. And unless the user is doing the same exact action again (not the next 'bit' of the same action), they won't be revisiting that run mode.

That said, I do at times go one step further, particularly for important forms. I'll dedicate a run mode just for the processing of the submitted data, and then send the user an HTTP redirect to the next mode. This is so that the user doesn't accidentally resubmit the same data with a refresh when they're on the next page.

An alternative I have thought of would be to re-use the same runmode, and check the value of the submit button which would tell me the user submitted the form. So each run mode function would handle displaying the form if the user has not submitted it, otherwise it would process the data.

You need to be careful about using the value of the submit button for tasks like this. In some broswers, pressing the enter key while a form element is active will submit the form, but the value of the submit button is not passed, as it was not physically clicked.

It is better to add a hidden field into the form that you can look for when checking to see if the user submitted a form.

As for your actualy question, I have used both techniques successfuly with CGI::Application, so it is really a matter of personal preference which method you choose to use.

- Cees

Note that you can have one run mode call another. For example, if the user calls the "submit" run mode, but some data is missing, you can call the "display" run mode, passing along some extra data about the input error.

In general I have decided that it is best to use a separate runmode for each action. One to render a form, one to process the submitted result. Then it is possible to easily use CGI::Application::validateRM for input validation and error presentation. The combination of these modules makes the process of managing forms and data rather easier than any other way I have tried.

Using a single runmode for form rendering and input processing narrows the choices you have for validation. It also has another interesting side effect - you can get better code re-use! I have found that the form processig runmode can often be re-used itself. The same basic logic is used to validate and process data for a single entity, say a database record, in possibly several places in an application. As an example, I have an appointment record (in an appointment management system) which is accessible either by the person wanting an appointment or the service provider. Validation and processing is the same regardless of the user, but the form presented is very different, often with different popup menues and defaults in the various cases. If I want to go to different places when the validation and processing is complete, I can just use the get_current_runmode method of CGI::Application and do a dispatch at the end of the runmode.

One cat, just more ways to skin it.

John

Don't worry about the rest of us out here. We are used to picking up code which is written in strange ways!

Thanks all for your input. There seems to be a good split between the two, so I will try both and see which I like better. For the reasons jdtoronto posted, I think I will like the idea of a separate run mode for processing the data. And thanks to perrin for the info about calling another run mode.