Hi jbdhl,
>
> 1) Should the Controller method, e.g. "update()", fetch the modified
> properties itself or should the View do it and provide the properties
> as arguments to the update() method?
>
There is some debate on what "controller" actually means. IMO it can
mean anything from, say, the event queue implementation within GWT
itself, a method like your update() example, or an RPC servlet method
(or a session EJB method called from one) that orchestrates a
transaction on the server, depending on who you talk to. My view is to
ignore this question: with update() what advantage is there in having
a second method in the view class collate widget values, then pass
them on to the update() to update the model? Well, there might be if
you are your model is broadcasting events to various other views in
the UI on update. In that case you might need a separate controller to
manage the model updates and coordinate event firing across multiple
views. Otherwise I wouldn't worry about this.
> 2) Should the Controller "know" the View and let the update() method
> manually call some refresh() method in the View after modifying the
> Model, or should the View just attach some sort of listener to the
> Model (or even Controller?) and the perform the refresh of the
> relevant parts itself?
>
I think a View should know its controllers and pass them only the
information they need to do their allotted tasks - i.e. decouple.
Controllers should not have references to views IMO. The exception to
this is if your update() method is located within a view class itself
and directly updates model objects, the simple case. Here update()
will obviously have private access to the widget's values anyway, so
this is not an issue, and perfectly acceptable.
> 3) In general: Who should "know" who in the MVC design and how should
> they "know" each other? How and by who are modifications on the Model
> performed (who reads the modified values/properties from the DOM) and
> how is the relevant parts of the View updated accordingly?
This is really the crux of your issue. I think you can go two ways,
the simple case and the complex case, depending on your application.
If each model object is rendered and manipulated by exactly one view
class, there is little to be gained by abstracting the model objects
away from the views that look after them. If on the other hand some
model objects are rendered and maybe updated by several views (i.e.
the is a M-M relationship between some model and view classes) then
you are likely to win by abstracting the model out and running true
MVC.
In that case I think the relationships should be:
view
/ \
controller \
\ /
\ /
model
The views use both controller and model objects. The controllers use
model objects but do not "know" their views. The model objects know
nothing of either controllers or views. They broadcast events as and
when they are changed (by controllers), and these events are listened
to by the views which update themselves accordingly. In pattern
parlance, the views are Observers and the model classes are Observed.
However, as I've mentioned, unless you really do have a M-M thing
going on between view and model classes, this might be considered over-
engineering.
regards
gregor
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
