MVC as it applies to a GWT app
stefoid
I have collected my thoughts about it below, can anyone comment? Im a
newbie to both the GWT and O design in general, so dont shoot me for
being ignorant.
----
A GWT application is thick-client, meaning that stuff happens without
a trip to the server. In a thin-client application, user events are
sent to the server, which does stuff and then sends the results back
to the client to display.
Most GUI applications are some variety of MVC pattern.
Model - the data and logic that defines your application.
View - the visual presentation of the model
Controller - controls how user interaction affects the model and/or
the view
In some MVC designs, the view listens for model change events then
interrogates the model. In others, the view doesn't know about the
model and vice versa - the controller is a mediator between them.
In a thick-client application, the model exists on the server, but
model data exists also on the client side so that it can be
manipulated without a trip to the server. A trip to the server is
only necessary when a change of the model data on the client needs to
be persisted, or when some complex operation or service is required
that is not available on the client.
GWT has widgets to implement the view. When a user interacts with a
widget, it generates an event that is sent to the controller. The
controller decides what to do with the event: update the view?
Update the model?
How is a change in the model propagated to the view? The model
generates a change event that is observed by either the view or the
controller. This is basically an asynchronous RPC call returning to
the client.
Summary:
The model is whatever data and logic exists on the server side, plus
some classes on the client side that exist to enable the model to be
changed without a trip to the server, where possible.
The view classes are widget classes provided by the GWT library.
The controller classes are client-side classes that aren't model
classes or GWT widget classes.
Sandy McArthur
view's state with the model and you don't want to do that. Just
because a TextBox can hold a String and a CheckBox can track a boolean
value doesn't mean you want to use them as such.
On 4/11/07, stefoid <steven...@yahoo.com> wrote:
> GWT has widgets to implement the view. When a user interacts with a
> widget, it generates an event that is sent to the controller. The
> controller decides what to do with the event: update the view?
> Update the model?
Depends, there are a number of ways to do the controller.
The simplest and least "proper" is for when the view changes, it just
calls the appropriate setter on the model. If your model doesn't
require error checking between properties or sets of information to be
updated at once this often works well enough. Other than the initial
setup the controller is being bypassed. I probably won't use this if
the changes need to be sent back to the server via RPC.
What I do the most is if I have to create a new part of the model
based on user input is create a local mini-model that the view
directly works on and then when the user clicks "Save" or "Apply" the
controller makes the necessary checks and then updates the app's
model, does the needed RPC, etc.
The most "pure" send all model updates to the controller first seems
like overkill to me except if you wanted every change to be
immediately sent via RPC back to the sever. Because of the
asynchronous nature of GWT's RPC, this would be rather hard to get
right.
> How is a change in the model propagated to the view? The model
> generates a change event that is observed by either the view or the
> controller. This is basically an asynchronous RPC call returning to
> the client.
GWTx provides web mode emulation for java.beans.PropertyChangeSupport
and related classes. That's what I use to signal the view that the
model has changed. Write a custom widget and be sure that in it's
onAttach method it adds itself (or a listener impl that can be shared)
to the model's list of PropertyChangeListeners and updates its view
in case changes were made while the widget was detached. And then in
the onDetach remove that listener instance, otherwise your Widget
could hang around in memory longer than needed. (I know the GWT docs
say don't override onAttach/onDetach, do it anyway and just be sure to
call super.onAttach()/super.onDetach() else things won't work.) This
way your view widgets can update themselves as changes come in from
either other widgets or from RPC.
GWTx: http://code.google.com/p/gwtx/
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
stefoid
application consitute view and what constitues controller.
The model is pretty obvious - its whatever is on the server side, if
anything, and whatever data and methods that is on the client side
that relates strictly to the domain and has nothing to do with the
GUI.
A widget has both presentation and functionality. A button widget,
for example, becomes indented when you click on it, and it does that
'by itself'. A list box can scroll and the rest of the app doesnt
neccessarilly have to know anything about it when it does, although
you can listen for these events if you want to.
Can we then categorize user-extended and composite widgets as View
classes? Its not until a widget needs to affect the model, or other
widgets (views), that we need to fire off an event to a controller.
Im thinking you can design a composite widget and categorize GWT
events into 'internal' or 'external' types. Internal events are
handled within the widget, because they have no impact on anything
other than the widget. External events are handled by a controller
that listens for them - the widget(view) does not know anything about
a particular controller or model, so it can be reused with different
controllers/models.
The controller is the thing which listens for view events, and then
decides whether the model needs to be updated or the event effects a
different view, or both. In a perfect world, the controller also
listens to the model for model change events - so the model isnt aware
of the controller. The controller decides what happens when the model
changes - generally a change in views (widgets)
Is this all fair enough? I guess one thing that is puzzling me
though, is do we really need to seperate the client-side model from
the controller? The reason for a seperation of model and controller
is so you can use different controllers with the model, presuamably so
you can use different views. However the model on the client side,
like the controller, is very much GWT dependent in that it is written
in java that is compiled to javascript, and it presumably uses GWT RPC
to talk to the server. You cant really port the client side of the
model to another framework, so why bother seperating client-side model
and controller?
If the seperation of client-side model and controller is uneccesary,
then you want to have as much of the model on the server-side as
possible, theoreticaly - then you have as much of your model as
portable as possible. However the flipside is that to make an AJAX
application more respnsive and AJAXy might require more model-ish code
on the client, so there is a bit of a tradeoff there....
Any comments?
Sandy McArthur
MVC is about maximizing code reuse.
M: Presumably you can use the model in web mode, in a Swing app, on
the server, etc. You don't have to make the model pure dumb. If an
Item's price should never be negative than in your model make the
setPrice(-1) throw an IllegalArgumentException. Just keep the Model's
logic rather generic.
V: You can reuse parts of the view if you are smart about them. For
example you create a DateLabel that knows how to show a Date like you
want in various places such as in the list of report create times, or
message sent times. Otherwise you have to write the
convert-a-Date-to-a-String-and-set-the-Label code a dozen of times in
a dozen of places. You won't be able to use a GWT DateLabel in a Swing
app, but once you create a Swing DateLabel you can use a familiar
feeling component in a different context.
C: Here is where you have the least amount of reuse. Each environment
will have it's own features and limits and at some point you have to
own up to that and deal with it. A GWT app (mostly) only works while
online, a Swing app can save data to a file system and work while
offline.
It may take ~50% longer to make a component reusable the first time
you write it, but the second time you need you'll probably break even
productivity-wise and a third, fourth, fifth time you need it you'll
turn a productivity profit. I've yet to have a project that didn't
grow in scope from initial conception to when it was "finished". Even
things I initially think I'll only use once more often than not get
reused.
Just start writing the code with a decent, but not absolute, level of
discipline and see what works for you and your project. You can think
and speculate all you want but that doesn't advance the project. In
the end, the result is what matters.
stefoid
> The simplest and least "proper" is for when the view changes, it just
> calls the appropriate setter on the model. If your model doesn't
> require error checking between properties or sets of information to be
> updated at once this often works well enough. Other than the initial
> setup the controller is being bypassed. I probably won't use this if
> the changes need to be sent back to the server via RPC.
>
> What I do the most is if I have to create a new part of the model
> based on user input is create a local mini-model that the view
> directly works on and then when the user clicks "Save" or "Apply" the
> controller makes the necessary checks and then updates the app's
> model, does the needed RPC, etc.
So the controller is in charge of persisting the client-side model
data through RPC? My initial thought was that the model decides what/
when to persist.
> The most "pure" send all model updates to the controller first seems
> like overkill to me except if you wanted every change to be
> immediately sent via RPC back to the sever. Because of the
> asynchronous nature of GWT's RPC, this would be rather hard to get
> right.
> > How is a change in the model propagated to the view? The model
> > generates a change event that is observed by either the view or the
> > controller. This is basically an asynchronous RPC call returning to
> > the client.
GWT widgets dont have this concept of data-binding. To change them
you call their API functions. I am currently looking at the GWTx data-
binding as it is described in 'GWT in practice'. It looks to me like
a user-extended composite widget that uses this method doesnt have to
know specifically about a model, but it does have to know specifically
about certain properties that it binds to. So you cant reuse this
widget except under the condition that you bind those specific
properties to it. Is my understanding correct?
Ian Bambury
> > The simplest and least "proper" is for when the view changes, it just
> > calls the appropriate setter on the model.
Here's my take:
M: Is easy, it it a model of the real world situation we are trying to, er, model.
V: It is a visual (probably) representation of the model. If the model is a boolean representing a light being on or off, then the view could be a picture of a lightbulb, lit or not, a picture of a switch in the right state, the words on or off, a Braille message, a real light bulb, or anything else you fancy, sun and moon, (even cat and dog pictures if it means something to someone). The View consists of view elements aggregated into larger and larger units.
C: The controller responds to events and changes in the realm.
It might change the layout/visibiliry of various aspects of the view. A simple example would be a couple of radio buttons deciding whether to show the temperature in Celsius or Fahrenheit.
In GWT, the first bit of Controller will wire up events in the model with the views so that a change of state in our model (indicated by a stateChange event or whatever) changes 'On' to 'Off' (or whatever). The actual changing of 'On' to 'Off' is a View thing, not a controller thing.
The initial bit of control code might also hook up a button's on-click event to the model's changeState() method by adding a clicklistener. All the code in the clicklistener is 'controller'
If the button is not only turning the lighbulb on and off, but also turns yellow or grey to indicate the bulb's state, then it is also .view'. You could argue that it is ALL 'view' and that the onClick code is 'controller', but what if it is just a button and doesn't show the bulb's state, what is it then? It's not 'view' because it doesn't tell you about the data, and it's not 'controller' because it is a bunch of pixels on the screen and not code that does any controlling.
Since it delegates responsibility for the click to the handler, call it a 'delegate'. If it shows data as well, then it is also part of the view.
The Model should only be a model of your data. Like Sandy says, it does not have to be stupid, but it is probably best if it is. There are things it should do but they are to maintain data integrity. Sandy's example of a negative price is borderline. If the data model still works if you pay people to take things away, then there's no reason to throw an error. It's a business decision not to do so and it belongs in the controller, same as if it were free, or if there is a minimum order quantity. You can fly a plane below sea level over the Dead Sea so constraints in the model should really be restricted to problems like data not fitting the model, like the number of people in the building being -1.
The model is entirely free from the view and the controller in that the view just shows what the model looks like from various angles, and the controller can only use the methods provided by the model: you don't change the model just because the controller decides it wants to turn the volume up on a bicycle.
The model changes if the business reality changes, or if more of the business reality is to be included in the system.
View elements can often be generic and reusable. An "On/Off" view element can be used for a lightbulb and a dog/sofa situation as well as the state of a relationship between two people.
View composites (i.e. lots of view elements packed together to show the interesting bits of a model e.g. a flight deck) get less and less reusable as they get more specific, of course.
Controller logic is the same as any code: there are reusable bits and unreusable bits, same as always.
So a really basic example would have a button (delegate) which when clicked kicks off an event handler (controller) which calls a method changeState() on a data object (model) which fires a change event to any interested ui elements (views) which were wired in by the onModuleLoad() event (controller).
Note that the controller doesn't feed back into the view. If the button changes colour depending on state, it is because a change of state in the model tells it to. That way, you know that the message has made it to the model and back, and if there is another switch somewhere else, this button is still showing the state of the model's data. The button is a) a delegate and b) part of the view and the two roles doen't mix.
stefoid
attributing way to much functionality to the controller. I think it
should have the minimum code neccessary to mediate between the model
and the views.
but having said that, Im struggling to think of any reasons to
seperate the client-side model from the controller stuff in a GWT
app.
Ian Bambury
charlie...@gmail.com
displaying that Model in some form, and a View delegating
responsibility for doing "stuff" to a Controller. (Which all, yes,
facilitates re-use on various levels.)
The Controller can update the Model, which again is being observed by
the View and so the View may change - but the Controller itself should
not manipulate the View.
In GWT, in my experience, you want the View to be your UI widget, and
you want separate *client side* Model and Controller representations
that have nothing to do with the View. You can then bind the View to
the Model using PropertyChangeSupport (GWTx, etc). So, part 1, if the
Model changes, the View, being an observer, changes in turn. Then in
response to UI events (click a button, etc) your UI can call a
Controller. The Controller then may call an RPC service to synchronize
the Model with the server side, may pass off to a logic "handler" on
the client side, or do any number of things. But, the Controller
itself should not have much "functionality," I would agree with that.
(This helps not only in termsseparation/clarity, but also in practical
re-use and testing - you don't have to much with UI level events in
your tests, once you have a client side Controller.)
Separating the client side model from the Controller is useful for the
data binding, PropertyChangeSupport stuff you can use in GWT. For
example you might have many UI widgets re-using certain model
components (and MVC comes in at many layers - I like a Controller per
Widget, but you may also have a macro-Controller other widgets pass
off to).
(And, please let me know what parts of GWT in Practice you are
checking out and any feedback you have. Ping me via email and I can
get you an updated version of the manuscript - the MEAP stuff is
outdated right now [but I think it will get an update soon]. For those
that haven't checked it out, please do - http://www.manning.com/cooper/
- the free Chapter, Chapter 1, really doesn't have any serious
details. It's an introduction to the overarching concepts of GWT, but
from then on MVC, data binding, JPA enabling models, RPC, building/
deploying/packaging/testing and so on all get a lot of coverage -
check out the ToC for more info.)
charlie...@gmail.com
all the lightbulb state stuff, what hours, who is authorized, etc.
Surely not. But it is also not the job of the Controller. That is
something the Controller should delegate to a business logic bean or
service. The controller should really be a traffic cop between the
layers, and not actually making or enforcing the laws (to strain
another analogy ;)).
On Apr 12, 9:35 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> So, if you are modelling a lightbulb, then the lightbulb should know what
> hours it can be lit (it needs to know time of day, and hours of business -
> in the HoB model), who is authorised to flick the switch (so the lighbulb
> model needs to know about the user model), who is authorised to change the
> lightbulb, who is on-call, (how many light-bulb-changers does it take to
> change a lightbulb?), their pager numbers, whether to page or email or
> sms...
>
> It's all too much for a simple light bulb model IMNSHO isn't it? And surely
> not the responsibility of the view?
>
> Ian
>
> --
> Ianhttp://roughian.com
Ian Bambury
The Controller can update the Model, which again is being observed by
the View and so the View may change - but the Controller itself should
not manipulate the View.
In GWT, in my experience, you want the View to be your UI widget, and
you want separate *client side* Model and Controller representations
that have nothing to do with the View. You can then bind the View to
the Model using PropertyChangeSupport (GWTx, etc). So, part 1, if the
Model changes, the View, being an observer, changes in turn. Then in
response to UI events (click a button, etc) your UI can call a
Controller. The Controller then may call an RPC service to synchronize
the Model with the server side, may pass off to a logic "handler" on
the client side, or do any number of things. But, the Controller
itself should not have much "functionality," I would agree with that.
I think you guys are both right. It's not the job of the View, to know
all the lightbulb state stuff, what hours, who is authorized, etc.
Surely not. But it is also not the job of the Controller. That is
something the Controller should delegate to a business logic bean or
service.
Ian
http://examples.roughian.com
stefoid
of your lightbulb component. What you have there is 'Building
Lighting Services' component, and those responsibilities are part of
your BLS model, not the BLS controller or BLS View. (except where the
BLS collects Lightbulb components)
On Apr 13, 4:57 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> On 12/04/07, charlie.coll...@gmail.com <charlie.coll...@gmail.com > wrote:
>
>
>
> > The Controller can update the Model, which again is being observed by
> > the View and so the View may change - but the Controller itself should
> > not manipulate the View.
>
> Well, to quote Steve Burbeck (his emphasis) "The *controller* interprets the
stefoid
On Apr 13, 1:30 am, "charlie.coll...@gmail.com"
<charlie.coll...@gmail.com> wrote:
> Putting GWT aside, MVC is basically a View observing a Model, and
> displaying that Model in some form, and a View delegating
> responsibility for doing "stuff" to a Controller. (Which all, yes,
> facilitates re-use on various levels.)
>
> The Controller can update the Model, which again is being observed by
> the View and so the View may change - but the Controller itself should
> not manipulate the View.
Whats the difference between update and manipulate?
> Separating the client side model from the Controller is useful for the
> data binding, PropertyChangeSupport stuff you can use in GWT. For
> example you might have many UI widgets re-using certain model
> components (and MVC comes in at many layers - I like a Controller per
> Widget, but you may also have a macro-Controller other widgets pass
> off to).
Does using databinding tie a widget to specific model properties?
Does it mean you cant you reuse the widget in a different context
within the same GWT application or another GWT application? (I admit
I have only scanned chapter 4 so far)
> (And, please let me know what parts of GWT in Practice you are
> checking out and any feedback you have. Ping me via email and I can
> get you an updated version of the manuscript - the MEAP stuff is
> outdated right now [but I think it will get an update soon]. For those
> that haven't checked it out, please do -http://www.manning.com/cooper/
> > > Ianhttp://examples.roughian.com- Hide quoted text -
>
> - Show quoted text -
Ian Bambury
stefoid
so ...
any help appreciated.
Ian Bambury wrote:
> OK. so we have a lightbulb component and now a BLS component. You still have
> to check if I am a supervisor somewhere, the M, V or C of one or the other.
> Or are you only using MVC for little bits of the application and the rest is
> "whatever".
A. user pushes a 'apply change' button (editing a dialog that controls
when the lights automatically turn on and off?)
q1) is the fact that a specific dialog is in focus a view-state thing
(controlled by the controller) or a model-state thing (controlled by
the model) ?
B. controller catches 'automatic light dialog' event. Controller
knows that when this event is received, it needs to alert the model by
calling 'update automatic lighting' function.
q2) How does the controller know this event corresponds to a certain
model function? There must be a view-state. I am guessing that the
controller is basically a state machine that responds to incoming
events from both the view and the model.
q3) how is the data in the view dialog passed from the view to the
model? I am guessing that the view pumps out the data in the event,
the controller then passes that to the model, possibly massaging it to
fit.
C. The model decides if the current user is a supervisor, (allowed to
change the automatic lighting) and if the lighting periods are
acceptable. Lets assume at this point that the model can do some
simple parsing of the data to detect inconsistancies like -ve lighting
periods, but has to go to the server to verify user authority.
q4) how is a simple error communicated to the user? Does the 'update
automatic lighting' function return an error code that the controller
uses to create a popup or some other change to the view to indicate
simple error?
D. sometime later, the server verifies the user and persists the
changes or not (bad user, server down, etc...). An event is generated
to indicate the update was successful or not. The controller
interprets whichever event and updates the view and view state
accordingly.
q5) how is the data in the model passed to the view(s) that need it
in response to the events? again, the controller probably gets the
data from the event itself and calls the appropriate view functions,
possibly massaging the data to fit.
so... in my scenario, the controller is a state machine that is highly
dependent on both the model and the view, but both of those things
arent dependent on the controller or each other at all.
However, Im wondering whether there needs to be this seperation of the
model and the controller on the client side of a GWT app? Maybe its
OK for the model and controller to be mashed together on the client
side to make a modtroller. The modtroller is view-compatible - it
knows about the view, even though the view doesnt know about it. It
only massages data to fit the real model on the server when it uses
RPC. I think this could be a good simplification. The 'client-side
model' in a GWT application isnt really reuseable in the way that the
server side model is. It is what it is precisely because we are using
GWT. If we port the project to a different environment, it would have
to be thrown away.
> But if the whole application is MVC, where does the supervisor check go?
The model IS your application. The View(s) is a graphical
representation of (parts) of the model. The controller sits between
both, translating user events for the model, and model events for the
view. This is my best interpretation of the widely varying opinions I
have trolled off the internet.
Data binding model properties to view properties seems to me to be a
shorthand way for 'model events' to get from the model to the view,
bypassing the controller in the process. However, I am concerned
about this introducing a dependency of the view on the model, seeing
as how the view seems to have the only reusable parts of the app.
Also, a lot of model change events are going to require a view-state
change anyway, so how much of a saving is data-binding anyway?
> --
Sandy McArthur
> I can try to work it out... I am not up on this data-binding thing,
> so ...
> any help appreciated.
Just start writing the code and you'll see and learn what it takes to
make it work. You'll learn more in less time that way than trying to
get a complete understand via a group discussion.
This whole discussion about what is the "right" way to do MVC is
basically bike shed argument. People are misunderstand each other, or
getting hung up on nits that don't matter in the scope of the bigger
picture.
stefoid
a convincing push in one direction or another!
Sandy McArthur
> I havent got the spare time to do this thing trial and error. I need
> a convincing push in one direction or another!
This thread was started two days ago. In that time you could have
prototyped a variety of quick MVC styles and made a reasonable choice.
Or you could have gone to a library or a book store and see if there
were any books at least indirectly about MVC.
stefoid
Ian Bambury
Hi Steven,
There's an example project here: http://examples.roughian.com/mvc_lightbulb.zip if you want something to discuss.
> A. user pushes a 'apply change' button
> (editing a dialog that controls
> when the lights automatically turn
> on and off?)
> q1) is the fact that a specific dialog
> is in focus a view-state thing (controlled
> by the controller) or a model-state thing
> (controlled by the model) ?
The model doesn't control anything outside the model
How it got focus is anyone's guess
> B. controller catches 'automatic light dialog' event. Controller
> knows that when this event is received, it needs to alert the model by
> calling 'update automatic lighting' function.
>
> q2) How does the controller know this event corresponds to a certain
> model function? There must be a view-state. I am guessing that the
> controller is basically a state machine that responds to incoming
> events from both the view and the model.
The controller has probably been invoked by an onClick from a button, therefore it knows what it is supposed to do which will be something like calling a method setAllowableTimes() on the model object
>
> q3) how is the data in the view dialog passed from the view to the
> model? I am guessing that the view pumps out the data in the event,
> the controller then passes that to the model, possibly massaging it to
> fit.
The view is a view of the data in the model. It has nothing to do with input. It gets hard to get your head round when, say a button controls the light and also displays "On" or "Off". To start with, have a label with "On" / "Off", and a plain button. The functions are completely separate even when combined into a single widget.
The data is on the screen and is part of the controller, as is the button. You could, for example, remove all views of the data and still control the light with the button, even if you lost track of whether the bulb was on or off.
>
> C. The model decides if the current user is a supervisor, (allowed to
> change the automatic lighting) and if the lighting periods are
> acceptable. Lets assume at this point that the model can do some
> simple parsing of the data to detect inconsistancies like -ve lighting
> periods, but has to go to the server to verify user authority.
>
> q4) how is a simple error communicated to the user? Does the 'update
> automatic lighting' function return an error code that the controller
> uses to create a popup or some other change to the view to indicate
> simple error?
I wouldn't worry about having copies of the data all over the place - models of models. Getting an understanding of the simplest scenario first is always useful for me.
>
> D. sometime later, the server verifies the user and persists the
> changes or not (bad user, server down, etc...). An event is generated
> to indicate the update was successful or not. The controller
> interprets whichever event and updates the view and view state
> accordingly.
>
> q5) how is the data in the model passed to the view(s) that need it
> in response to the events? again, the controller probably gets the
> data from the event itself and calls the appropriate view functions,
> possibly massaging the data to fit.
The model informs any interested bits of software. In GWT (and in the example) this is done by raising an event to registered listeners.
>
> so... in my scenario, the controller is a state machine that is highly
> dependent on both the model and the view, but both of those things
> arent dependent on the controller or each other at all.
Not in my understanding. The model is not tied to anything else. It can be interrogated and return information, and it will inform registered listeners if state changes.
The view reflects the state of all or part of the model. When brought into existence, it interrogates the model to set its initial settings. It also listens for and reacts to events.
You could have a controller which is just one chunk of code endlessly looping or running on a timer. It would check everything there is to check as far as input is concerned and react to that input.
In practice, that controller code is split into the different parts that deal with different input and each part runs in response to one or more events. You can look at that as controller code being distributed, or you can look at it as lots of little controllers.
> > But if the whole application is MVC, where does the supervisor check go?
>
> The model IS your application.
No it's not. The model is tha data held in my application. The view is the data displayed in some form, and the controller reacts to events. Any not used by one or another of the M, V and C, isn't used at all.
>
> Data binding model properties to view properties seems to me to be a
> shorthand way for 'model events' to get from the model to the view,
Data binding wires model events directly to handlers in the view when there is nothing to do in between. But it is the controller which links the view directly to the model.
model --> view
If you were displaying a list of names and telephone numbers you could do this, too. But if you wanted to add filters then you would wire it up through a filter (a controller or a bit of one) via a common interface
model --> sort --> view
model --> dial-code-filter --> view
model --> dial-code-filter --> sort --> view
obviously there are easier ways to do this in a database, but if the data was in a flat file you'd have to do it this way.
> bypassing the controller in the process. However, I am concerned
> about this introducing a dependency of the view on the model, seeing
> as how the view seems to have the only reusable parts of the app.
The view is dependent on the model, has to be since it is displaying it, but that doesn't mean that individual components in the view can't be reused. A listbox for example can display any list data.
> Also, a lot of model change events are going to require a view-state
> change anyway, so how much of a saving is data-binding anyway?
It's a saving because you cut out the middleman
Ian
>
charlie...@gmail.com
(and many patterns recur at various layers, a Button itself uses MVC
also), but it is not the only stuff in an application. "Then what is
it?" It is whatever you want to use, OUTSIDE of MVC, if it is
business logic (what hours can the lightbulb be on) then it has
nothing to do with the UI oriented MVC.
For example, we all recall the Struts days when lots of people put all
kinds of logic in their "Action" classes. Action classes in Struts are
really an extension of the controller, and the Struts (1.x)
documentation says:
"It is wise to avoid creating lengthy and complex Action classes. If
you start to embed too much logic in the Action class itself, you will
begin to find the Action class hard to understand, maintain, and
impossible to reuse. Rather than creating overly complex Action
classes, it is generally a good practice to move most of the
persistence, and "business logic" to a separate application layer. "
Now of course I am not comparing Struts to GWT, but I am trying to
illuminate the fact that the "Controller" should not have a lot going
on besides delegation. You might choose to use another "Model" layer
outside of your UI related GWT MVC to house your "business logic
beans" and that is clearly where "lighbulb hours" goes. It may or may
not be called a "Model" then, because that just gets confusing (thats
what Struts calls it though, more of the Model), but there is a layer
of application stuff (hopefully re-usable outside of GWT altogether)
that has nothing to do with the UI controller (Struts or GWT, or
whatever else).
On Apr 12, 2:57 pm, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> On 12/04/07, charlie.coll...@gmail.com <charlie.coll...@gmail.com > wrote:
>
>
>
> > The Controller can update the Model, which again is being observed by
> > the View and so the View may change - but the Controller itself should
> > not manipulate the View.
>
> Well, to quote Steve Burbeck (his emphasis) "The *controller* interprets the
charlie...@gmail.com
terms of the terms themselves really, the difference is the
"separation of responsibilities" again, which layer it happens on.
I said the "Controller can update the Model" and "the Controller
should not manipulate the View." Same difference if update and
manipulate are interchanged there, or either is used in both places.
The point was Controller->CHANGE->Model, and Controller|NOT CHANGE|
View.
The View observes the Model and invokes the Controller to do stuff.
The Controller changes the Model (or delegates to other layers that
end up changing the Model, etc). The Controller though, never talks to
the View, and the View could be entirely changed out, using the same
Model and Controller, and it would make no different to the Model or
Controller. That is key, if anything goes the other way and interacts
directly with the View, then the View is now permanently part of the
design, and that is what MVC is trying to avoid/separate.
As to "Does using databinding tie a widget to specific model
properties?
. . ." - Fantastic question, and one that the very fact you posed it
makes me want to go back over Chapters 2 and 4 (4 is now actually 5)
and specifically address this more. I do not think you will find a
direct answer to that in the book as is, but it sure should be there.
This can be handled different ways, but I think databinding DOES tie a
Widget to a specific Model. Again though, this goes back to my above
thinking on MVC. The View is the throw away part. The View is
observing the Model and invoking the Controller. You could make a new
View and call the same Controller methods, using the same Model, re-
using the MC parts, but you cannot re-use the V part without the MC
parts. In my mind, this is an advantage. I can re-use the same
Controller and Model (even if they are translatable GWT "client"
components") and bolt another View onto them. But a particular View
is bound to a particular Model/Controller. In GWT then I can have a
library of Widgets, that are MVC constructed, and some may re-use
Model and Controller components, but each View is a new way to expose
some part of a Model and a set of operations on that Model (the View
itself is worthless without that Model).
> > > > Ianhttp://examples.roughian.com-Hide quoted text -
Ian Bambury
Ian Bambury
charlie...@gmail.com
delegation layer, your business logic goes in the "Model" technically,
but I try to avoid calling it Model because I like to think of Model
as simple POJO's, data related, such as in JPA. I distinguish Model
into two parts, Data and Logic (and like to call the Logic part
"business logic layer," but in MVC terms its part of the Model, its
just an important distinction of those sub-layers).
What hours a light bulb should be on, has nothing whatsoever to do
with "control logic."
And, as to "If the views are never manipulated by a controller, how do
you change from
one view to another? ", that is pertaining to a different level of
MVC. As I said this stuff happens on various levels. In that
instance I was speaking in terms of within a single Widget, each
Widget has MVC. The entire application may have another layer of MVC,
and may have a "macro" controller that can swap in and out parts of
the View (individual Widgets), but it still does not manipulate any
particular View component (it composes the overall View, from the
available Widgets by delegation, you are up now, you are finished,
next you, etc.). In GWT terms this gets even more varied because you
can have multiple entry points, or multiple entire apps, in the same
context of one "web application", but in general you can have MVC at
many levels.
On Apr 13, 10:24 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> So it's a matter of definition: You say that the controller is just a name
> for the top-level routine, and I say that if move code into a subroutine it
> is still part of the controller because it is still part of the control
> logic.
>
> --
> Ianhttp://roughian.com
charlie...@gmail.com
data binding the View does manipulate the Model directly, but that
doesn't count ;). When it is only accessors and mutators, as in the
View calls "setUsername" on the Model directly, thereby invoking
PropertyChangeSupport to fire, that is really still part of the
"Controller" layer in my mind. It is a convention for the Model to
allow *anything* to update it, and then observers to be notified,
whether that happens from a component named "MyController" or directly
from a View widget is really less important (the layers cross
component boundaries in that sense).
On Apr 13, 10:23 am, "charlie.coll...@gmail.com"
> ...
>
> read more »
Luciano Broussal
I like MVC. But Warning. don't wish that everybody create is own MVC
framework based on GWT and at the end that will be the same spagetti
mastermind to choose what is the best framework like it is a case
today for Jsp/servlet framework where you can spend more time to
choose a frame work (+40) instead of spending efforts on the businnes
project itself.
For me after experience ( the simple Bean model + jstl was the best).
Keep it simple please.
Regards.
Luciano
On 13 avr, 17:13, "charlie.coll...@gmail.com"
stefoid
> The Controller changes the Model (or delegates to other layers that
> end up changing the Model, etc). The Controller though, never talks to
> the View, and the View could be entirely changed out, using the same
> Model and Controller, and it would make no different to the Model or
> Controller. That is key, if anything goes the other way and interacts
> directly with the View, then the View is now permanently part of the
> design, and that is what MVC is trying to avoid/separate.
This is one of the major points I wanted to bring up, because there
are differing opinions on it. "the view obseves the model" means that
the view is tied to the model and you cant reuse that view component
in a different context. whereas GWT widgets, which constitute view
components (do you agree?) dont work that way - they can be reused.
> As to "Does using databinding tie a widget to specific model
> properties?
> . . ." - Fantastic question, and one that the very fact you posed it
> makes me want to go back over Chapters 2 and 4 (4 is now actually 5)
> and specifically address this more. I do not think you will find a
> direct answer to that in the book as is, but it sure should be there.
>
> This can be handled different ways, but I think databinding DOES tie a
> Widget to a specific Model. Again though, this goes back to my above
> thinking on MVC. The View is the throw away part. The View is
> observing the Model and invoking the Controller. You could make a new
> View and call the same Controller methods, using the same Model, re-
> using the MC parts, but you cannot re-use the V part without the MC
> parts. In my mind, this is an advantage. I can re-use the same
> Controller and Model (even if they are translatable GWT "client"
> components") and bolt another View onto them. But a particular View
> is bound to a particular Model/Controller. In GWT then I can have a
> library of Widgets, that are MVC constructed, and some may re-use
> Model and Controller components, but each View is a new way to expose
> some part of a Model and a set of operations on that Model (the View
> itself is worthless without that Model).
Could we try an ultra simple example? Lets try ians lightbulb.
Lets say, for the purposes of this exmaple, that it comprises two re-
usable components, both of which use MVC. One sub-component is a
switch button that can be up or down. The other component is a
lightbulb dialog that contains a switch button. Two layers of MVC.
The logic for the lightbulb component says 'when the switch is down, I
am on, and when the switch is up, I am off''
Could you explain which bits constitute MVC and how they interact? I
think this will also account for your last post concerning multiple
layers of MVC.
Steve
> ...
>
> read more »- Hide quoted text -
charlie...@gmail.com
the "toolkit" nature of GWT (as opposed to a framework). Rather than
try to explain these abstractions further with more words I am going
to step back and create a "GWT MVC" example project - get to some
code. This might take me a few day or so to throw together, but once
I have it I will send it to you guys (Steve, Ian, Luciano). And after
we argue about it offline ;), maybe we will have something of an ultra
simple example we can all agree on and we can then repost here (or
host somewhere like gCode or Roughian, etc).
> ...
>
> read more »
Ian Bambury
Ian Bambury
stefoid
aforementioned switch widget.
stefoid
contains the switch widget could also be a reusable widget. and so
on, and so on.
The internals of these widgets are their own private MVC. These could
operate as per Charlies architecture - view observes model etc...
(although I have seen MVC described elsewhere where the controller
observes the model and sets the view)
But regardless of how the internals is implemented, so far I get the
above.
The interesting/confusing thing for me now is how these seperate MVC
based elements interact.
For instance,is the switch widget is part of the view of the lightbulb
dialog? . Or the controller?
Who initializes the switch's model? And how is it done?
we arent arguing are we charlie?
> > Ian- Hide quoted text -
Ian Bambury
Before we confuse the issue with multiple levels of MVC, let's have a lightbulb example
The problem is this: You spend a lot of time in your study playing with GWT on the computer and, at night, you want to know if the security light at the front of the house is triggered or not. You decide you want a little picture of the security light in the system tray of your computer which shows the state of the light.
To monitor the light, you buy a USB light sensitive switch which can be monitored in your program with an 'onLightOn()' event and an 'onLightOff()' event very similar to plugging a mouse into the USB port and firing an onMouseDown() and onMouseUp() event.
We can't interrogate the light sensitive switch, so we have to create a model of the real world by creating a SecurityLightModel class and holding the light's state in a private boolean with a getter and a setter.
It also allows for interested things to be informed when the state of the lightbulb changes ecause it will broadcast a message to anything which is registered and a 'watcher'.
The SecurityLightModel class will use an interface which we just made up which we called a LightWatcher interface which has one method, 'onLitStatusChange(boolean state)'.
We need this because a) the SecurityLightModel class has to do something consistent or else it will need to know what the registered watchers are expecting, the converse of theis is b) the watchers need to know how to conform to what te model is going to do. So we have an agreement, the interface.
The model can register watchers and remove watchers.
In the setter, it calls a routine 'fireWatchers(boolean state)' wich runs through all the watchers in the list and effectively runs their onLitStatusChange(boolean state)' method.
This is the M of my system
We also have code for the two events, the onLightOn()' event and the 'onLightOff()' event. Depending on semantics, tou can call these part of the controller code, or separate controllers. The first calls ' model.setLightOn(true)' and the second 'model.setLightOn(false)' (obviously).
We then build a LightView class. This implements the LightWatcher interface in that is a) says so, and b) has an 'onLitStatusChange(boolean state)' method.
In the view, the onLitStatusChange(boolean state) method changes the lightbulb colour to yellow or grey depending on the 'state' variable passed to it.
The view has a private 'SecurityLightModel source' variable with a getter and setter
Note that it won't do anything yet. Apart from having to ensure it is shown on the screen, the view doesn't know of the existence of the model.
There are various ways to do this, but the cleanest if for the startup code to set the view's source to the instance of the model. In the setter, the view would register as a watcher of the model so it can be informed of events, it would also interrogate the model at this time so that it can set itself up ( i.e. show a yellow or grey bulb depending on the state of the model).
So now it is all set up. When the security light comes on, the USB light sensitive switch causes the 'onLightOn()' event or 'onLightOff()' event to fire. The controller passes it to the model which sets the boolean to the appropriate value, and the model tells the watchers (in this case our view) which sets the little lightbulb picture to the correct one.
This is about as easy a setup as I can think up. This is why I would call a button in the screen a 'control' - part of the UI, yes, but not part of the view. 'View' for me is just the stuff showing you what's in the model and as this example shows, if it is not on the screen it can still do the job and is therefore not 'view'.
Charlie said "The View observes the Model and invokes the Controller to do stuff." I disagree. The view doesn't invoke anything. Where it gets complicated is when a button, say, shows a picture of a lightbulb to show the state of the model AND to control it, but this is lke dual nationality, having two passports, and bloody confusing if you are trying to learn MVC.
But now you can replace the USB light sensitive switch with an on-screen switch and (in my view) see the switch just as a control. The actual security light is out of the system, too.
The up/down images are NOT part of the Security Light System view because they are a view of the switch state ( i.e. it will still show up or down whatever the state of the switch, even if not connected to the SecurityLightModel or if there is an error in your code). It is a separate MVC system within itself, and just a control as far as the Security Light System is concerned.
So, finally, I've got to your dialogue. I'll just sit here and wait for someone to tell me I'm completely wrong :-)
Ian
charlie...@gmail.com
or project are you referring to?
I have been working on writing and revising a simple example this
weekend, I will send it to you guys in the next day or so.
Basically my thoughts on MVC boil down to some of the stuff Martin
Fowler communicates (whether or not even he is more clear about it I
am not sure ;)).
http://www.martinfowler.com/eaaDev/uiArchs.html
Two key parts of what he says jump out though:
"So now I think it's time for some soundbites on MVC.
* Make a strong separation between presentation (view &
controller) and domain (model) - Separated Presentation.
* Divide GUI widgets into a controller (for reacting to user
stimulus) and view (for displaying the state of the model). Controller
and view should (mostly) not communicate directly but through the
model.
* Have views (and controllers) observe the model to allow multiple
widgets to update without needed to communicate directly - Observer
Synchronization"
and
"At this point I should stress that there's not just one view and
controller, you have a view-controller pair for each element of the
screen, each of the controls and the screen as a whole. "
How this is manifest in GWT is the question, hopefully some code will
help come close.
Ian Bambury
* Divide GUI widgets into a controller (for reacting to user
stimulus) and view (for displaying the state of the model). Controller
and view should (mostly) not communicate directly but through the
model.
stefoid
One thing I realize I have been stumped over is the context of the
model. In general terms, an the entire application has one model,
most of which is likely to be on the server where data is pesisted and
there are various rules for reading it and changing it. Lets call
this the APP model.
On the other hand, each screen, or in fact each little widget has its
OWN model. Its own MVC or MVP triad.
When we say that a view observes the model, are we talking about its
OWN model, or the APP model?
Im guessing its OWN model.
So how does each MVC/MVP triade comunicate?
My guess is that the parent object initializes the child object
through API functions.
The child object communicates to the parent objects via firing events
that the parent listens to.
Is this fair enough?
Ian Bambury
One thing I realize I have been stumped over is the context of the
model. In general terms, an the entire application has one model,
most of which is likely to be on the server where data is pesisted and
there are various rules for reading it and changing it. Lets call
this the APP model.
On the other hand, each screen, or in fact each little widget has its
OWN model. Its own MVC or MVP triad.
When we say that a view observes the model, are we talking about its
OWN model, or the APP model?
Im guessing its OWN model.
So how does each MVC/MVP triade comunicate?
My guess is that the parent object initializes the child object
through API functions.
The child object communicates to the parent objects via firing events
that the parent listens to.
Ian
http://roughian.com
charlie...@gmail.com
hiding a few things from me. That is on track in general I think.
Unfortunately I created my own example tonight, before I saw this
message. Mine could also be "tidier" and needs some feedback loop
stuff. I am going to email it to you and stefoid, and we can continue
the discussion there. Once we agree on an approach then maybe we can
come back to this thread and point to it.
On Apr 15, 9:22 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> Hi Charlie,
>
> I posted this linkhttp://examples.roughian.com/mvc_lightbulb.zipa couple
> --
> Ianhttp://roughian.com
charlie...@gmail.com
few emails about MVC architecture in GWT. At this point I think its
safe to say that among us, we do not agree (and we all submitted code
samples back and forth).
Even though we don't agree, thats also just fine, once again the
toolkit nature of GWT means this stuff can be done a number of ways.
I think GWT falls clearly into some MVC patterns, along the lines of
Swing/AWT. The first time I went about applying such patterns I ended
up with tightly bound view/controller pairs, and a separate model. I
call the view/controller pair the "throw away" part - meaning I can
build another view/controller and use the same model, but the view and
controller themselves have to "know" about one another. Of course as
much as possible the controller should NOT have view elements in it
(you should not pass a Label to a controller method, instead you
should have the Label in the view Widget observe the model - this
makes GWT testing later a LOT easier). Even when keeping things as
clean as possible though, the view "knows" to call X controller method
when something happens. Sometimes the controller can also be re-used
with another view, but its not as clear a separation as with the view/
controller and the model. The reason we still have view/controller is
that the controller, though associated with the view, has no view
elements in it, and this makes refactory/testing/organization much
improved.
After, through trial and error, I came to these conclusions I then
*later* found out about the Swing "Delegate" and "Separate Model
Pattern." I even ended up with similar "getModel" and "setModel"
interfaces (or using constructors with abstract classes). Basically,
in a roundabout way, I ended up with the same pattern. It's rooted in
"MVC" but its really "separable model." (Using bound properties and
PropertyChangeSupport - as implemented in GWT by GWTx.)
http://java.sun.com/products/jfc/tsc/articles/architecture/
On Apr 16, 11:01 pm, "charlie.coll...@gmail.com"
charlie...@gmail.com
patterns that others might be interested in. HMVC -
http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc_p.html,
which is a modifed form of PAC - http://en.wikipedia.org/wiki/HMVC.
Over the years apparently a *lot* of folks have come up against this
with UI toolkits and wanted to frame things in, e.g. create a
framework around the toolkit.
There are several Swing/AWT MVC frameworks around, and people in Swing
terms have discussed this for a long time.
The end result of all of this seems to have culminated in JSR-296, the
Swing Application Framework. http://jcp.org/en/jsr/detail?id=296
I can't read the JSR at present (the site is "down for maintenance")
but have seen a few other tidbits about it (http://www.artima.com/
lejava/articles/swingframework.html). The "action" and "gui design"
portions might apply to GWT applications. A lot of the rest of it,
multithreading and deployment, are of course not issues in GWT land.
If the JSR does address general app building design patterns,
(Apparently hans also did a presentation at last years JavaOne, I
missed it.) More to research here - https://appframework.dev.java.net/.
At any rate the point is, we can probably learn a ton from Swing
developers, and much of that knowledge should translate in some form
or another to GWT (its a "fat", or at least "chubby", client, it just
happens to use the browser as it's virtual machine once things are
deployed).
On Apr 20, 1:03 pm, "charlie.coll...@gmail.com"
Andre Freller
Charlie,
Thank you for sharing your research with us. I think this is the first pattern I've seen suitable for GWT.
Regards,
Freller
Shripad
will be possible to user multi threading in Swing and not in GWT. I
kind of looked at MVP pattern i.e. Controllers updates model as well
as view for GWT. One of the major issues I faced was how do we make
View - Controller interaction independent sync-async behavior. Please
consider following scenarios
Controller making an Async call to Server to get data and update model
and controller updates view from model data stored on client.
Regards,
Shripad
On Apr 21, 6:27 am, "charlie.coll...@gmail.com"
<charlie.coll...@gmail.com> wrote:
> After a bit more research I also came across some related ideas/
> patterns that others might be interested in. HMVC -http://www.javaworld.com/javaworld/jw-07-2000/jw-0721-hmvc_p.html,
> which is a modifed form of PAC -http://en.wikipedia.org/wiki/HMVC.
> Over the years apparently a *lot* of folks have come up against this
> with UI toolkits and wanted to frame things in, e.g. create a
> framework around the toolkit.
>
> There are several Swing/AWTMVCframeworks around, and people in Swing
> terms have discussed this for a long time.
>
> The end result of all of this seems to have culminated in JSR-296, the
> Swing Application Framework. http://jcp.org/en/jsr/detail?id=296
>
> I can't read the JSR at present (the site is "down for maintenance")
> but have seen a few other tidbits about it (http://www.artima.com/
> lejava/articles/swingframework.html). The "action" and "gui design"
> portions might apply to GWT applications. A lot of the rest of it,
> multithreading and deployment, are of course not issues in GWT land.
> If the JSR does address general app building design patterns,
> (Apparently hans also did a presentation at last years JavaOne, I
> missed it.) More to research here -https://appframework.dev.java.net/.
>
> At any rate the point is, we can probably learn a ton from Swing
> developers, and much of that knowledge should translate in some form
> or another to GWT (its a "fat", or at least "chubby", client, it just
> happens to use the browser as it's virtual machine once things are
> deployed).
>
> On Apr 20, 1:03 pm, "charlie.coll...@gmail.com"
>
> <charlie.coll...@gmail.com> wrote:
> > Just to cap this off, Steve, Ian, and I, have gone back in forth in a
> > few emails aboutMVCarchitecture in GWT. At this point I think its
> > safe to say that among us, we do not agree (and we all submitted code
> > samples back and forth).
>
> > Even though we don't agree, thats also just fine, once again the
> > toolkit nature of GWT means this stuff can be done a number of ways.
>
> > I think GWT falls clearly into someMVCpatterns, along the lines of
> > > > > Basically my thoughts onMVCboil down to some of the stuff Martin