Re: Validating form input data

"David Haynes" <david.haynes2@sympatico.ca> wrote in message
news:o9b5g.4106$lJ6.1001@fe69.usenetserver.com...

> It is more concise but suffers from marrying the view to the business
> logic. If you want to update the view, say for supporting cell phones or
> separating web page creation from the business logic, then it is easier
> under MVC than in a monolithic form.

Yes, that is true. If that is the case, i assume the controller will
redirect to the appropriate view suited to the client's equipment (or rather
browser), am i right?

> Both work. Which is best for you depends upon your needs.
>
> One thing I like about MVC is that the controllers and view all follow
> the same general format which makes understanding a new page easier.
>
> Controllers condition their environment, handle any POST/GET data, set
> the SESSION and redirect.

In your original post you implied that the controller can also contain
insert/update (into database) actions. Should the controller redirect to
another page that handles this stuff? It does not really matter in the
situation i am involved in right now, but i want to stick to correct
guidelines.

> Views bring in any SESSION data, set up for internationalization and
> paint the form.
>
> Obviously, you can combine the controller and view into one page. I find
> that the resulting pages can get to be quite large (lines of code) and
> complex (lots of business logic) which gets in the way on understanding
> how the page is being defined (i.e. the HTML)

What i did was combine some of the controller's logic into the the form's
page. If alla data is valid the user gets redirected to another page which
handles database actions. I did this because i found passing around data
through the SESSION variable a bit clumsy. However, i can see the advantages
of the MVC model you suggest. Thank you again for the detailed explanation.
Received on Mon May 1 03:08:14 2006