Re: Model-View-Presenter (MVP) question

On 24 Nov 2005 06:24:00 -0800, kaspar.thommen@xxxxxxxxx wrote:

>
>However, in my case, I have to do user input data validation. Assume we
>are presenting customer data which the user can modify. If I press the
>"Next Customer" button in the View, I first want to prompt the user to
>either save or not save the modification before presenting the next
>customer's data.
>
>The question is now: Does the Presenter class have to know this? In
>other words: When I click "Next Customer", shall the Presenter class
>already read customer data from the view and send it to the Model for
>validation, or shall it just tell the Model "Hey, the user has clicked
>'Next Customer' - now do whatever you want", which, in turn, makes the
>Model ask the Presenter to get customer data from the View?


>It all boils down to the question: Is the Model allowed to know about
>the Presenter? I see the following pros and cons:

No.

If you develop your web app (client) and web service (server side)
first, its likely that you will sovled this problem.

The termanoligy is wrong as well. Call it view-controller-model and
it helps you define the problem (i can see why its incorrectly called
presenter tho).

Controller has the responsibility for loading screens and translating
keyboard/mouse input into business events for the model as well as
taking date from the view and putting it in the model (use a momento
to do this).

The model does the validation of the data, but the screen (view)
should at least make sure that data is entered in the correct format
(you'd realise this if you did the app as a web form first)

eg. The view would contain only enough logic to ensure that a date
was entered and that it was in the correct format. (this is basic gui
validation - you'd do it as javascript or something in a web app)

The model would check it to be a valid date for the purpose that its
required for (eg. you cant enter a date of birth thats in the
future). The reason that this is done on the model, is because its a
business rule and not related to GUI processing.

---
A little gotchya tho. While GUI translation may be good in the view
for a web app, you probably really want it in the controller. The
reason is that if you keep it in the view, every date field you have
will require a validation routine and a set of associated rules.
Whereis when its moved to the controller, it requires only one copy of
the date routine and one copy of the validation rules (business rules
still reside in the model tho).

Keeping it in the controller also facilitates porting to other
platforms (such as X).


.

Quantcast