Post by MyiSeries Post by Joanna Carter (TeamB)
Validation can be done in the Model of MVP.
When the model knows there is a sintax error (say: "customer code is
already inserted in the custmer table") it has to send message to the
controller to tell to it: "Hey, bad code!".
Well, does the Controller has to ask the question: "Model, check this code"?
Or maybe, the Model has to 'Notify' (implementing Observer pattern) state
changes? In this way I think I've got to create a customized protocol to
exchange messages between Model and Controller.
I believe the best way to handle these situations is to do any setting of
values in the Model within a try..except block. This way the Controller
simply tries to set the value and catches any exception, feeding back the
result of the exception to the View or to another 'sub-view' that displays
the error, possiblt resetting focus to the offending edit.
Post by MyiSeries
I've looked at you articles. I've founded very interesting and more
sophisticated, too. But, as a first step, I'm trying to write code following
the MVC using less code than the MVP.
The real difference between MVC and MVP is that the 'message flow' is
handled via two different 'channels', one for each direction.
The user makes a Gesture in the View
An Interactor responds to that Gesture (that Interactor may delegate
reponsibility to nested Interactors, dependent on the complexity of the
If that Gesture is intended to alter the visual selection in the View, the
Interactor notifies the Selection in the Model.
Changes to the Selection are observed but he View and it is updated to
The Selection then notifies any Observers, one of which will be the View
which will update itself accordingly, the other is the Command Set.
The Command Set updates itself based on the Selection to accomodate things
like Commands not being available when more than one/only one item are/is
Assuming that the Selection is now up to date, the Interactor translates
subsequent Gestures, determines which Command on the Model is to be called
and calls this Command.
Commands can be undone and redone and can alos support the concept of a
history if required.
If executing the Command raises an exception, then the Interactor is
responsible for creating a Presenter for that exception and directing the UI
to a suitable focus point.
Assuming the Command succeeds, the Model, which contains the Value Type is
passes the change to the Value Type.
The Value Type responds to the change by notifying any Observers, one of
which would be the View.
This structure is more flexible in that Interactors and Commands can be
relatively freely substituted depending on the nature of either the View or
MVPs can also be nested, so you get a MVP 'component' for a BO, the View of
which will be a form, but this component will contain other MVP components,
one for each of the properties of the BO, the views of which will be the
edits on the form.
The inner MVP components can be created at runtime based on the names of the
BO properties matching the 'PropertyName' of the relevant edit on the form.
I tend to talk about creating Presenters for Value Types; this then means
that your client code usually creates/retrieves a Value Type (a BO is a
composite Value Type) and then simply passes that Value Type to the
constructor of a Presenter. The Presenter is responsible for creating a form
or other display and will self-destruct when the form closes.
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker