Initialising the View

[VisionSet]

More MVC stuff.

In a View you may do this:

class View {
Model model;
View() {
model = Model.getInstance();
setupGUI();
}
}

Now my model when instantiated goes off and deserialises a bunch of stuff
and all this stuff fires events at the view to notify its initial values.

But the view hasn't set up its GUI at this point so fails to be initialised
correctly.

Another approach would be to set up the GUI and then ask the model for its
intial values, but this duplicates the way widget models are updated.

Another approach would be to explicitly request the model to notify all
listeners/observers of its complete state on demand.

Another approach would to instantiate the model as the LAST thing I do

How is it best to handle the initialisation of the GUI?

[The getInstance() approach... The 1st view to be instantiated will cause
the model to be instantiated, future views will get this same instance.
With that in mind, perhaps it is pointless to fire events at time of Model
instantiation, only the 1st view will receive the events, highlighting the
requirement that perhaps the views should poll the model for initial
update?]

 

[Chris Uppal]

Another approach would be to explicitly request the model to notify all
listeners/observers of its complete state on demand.

Two patterns that I've used a lot for this.

Say you have a Model with a state, colour, and which sends
notifyColourChanged().

Version 1) The model, as a matter of contract, will automatically notify any
observers of its colour when it adds them to its listener list:
// in the Model class
addListener(ColourChangeListener listener)
{
listeners.add(listener);
listener.notifyColourChanged();
}

Version 2) The View (or whatever) as a matter of convention invokes its own
notification at the time when it connects to the Model:
// in the Observer class
observeModel(Model model)
{
model.addListener(this);
this.notifyColourChanged();
}

In the common case where what it really being observed is the /state/ of the
model, rather than events that are significant in their own right, I prefer the
first form. It's cleaner, less repetitive and, IMO, puts the responsibility in
the right place. Still, either works perfectly well, although you don't really
want to be mixing the two. For that reason I've tended to use the second form
in recent years, since I've been using a framework that uses the second form
extensively.

-- chris

 

[Rogan Dawes]

More MVC stuff.

In a View you may do this:

class View {
Model model;
View() {
model = Model.getInstance();
setupGUI();
}
}

Now my model when instantiated goes off and deserialises a bunch of stuff
and all this stuff fires events at the view to notify its initial values.

Never mind that the GUI has not been set up, there is no listener added
to your model either, so you would not get any events anyway.

But the view hasn't set up its GUI at this point so fails to be initialised
correctly.

Another approach would be to set up the GUI and then ask the model for its
intial values, but this duplicates the way widget models are updated.

Seems like the right way to do it, though.

Another approach would be to explicitly request the model to notify all
listeners/observers of its complete state on demand.

Assuming that all observers need to know the complete state. And that it
is not too expensive to completely refresh all your listeners, this
might work.

An alternative might be to have the model notify any new listeners as to
its current state, when the listener is being added to the model.

Another approach would to instantiate the model as the LAST thing I do

Your approach of initialising the model on instantiation seems to be the
problem, in my opinion.

How is it best to handle the initialisation of the GUI?

[The getInstance() approach... The 1st view to be instantiated will cause
the model to be instantiated, future views will get this same instance.
With that in mind, perhaps it is pointless to fire events at time of Model
instantiation, only the 1st view will receive the events, highlighting the
requirement that perhaps the views should poll the model for initial
update?]

As you suggest there are a couple of ways of approaching this:

1.

class View {
Model model;
View() {
setupGUI();
model = Model.getInstance();
model.addListener(this);
}
}

where model fires its entire state at the new listener as it is added.

Or:

2.

class View {
Model model;
View() {
model = Model.getInstance();
setupGUI();
model.addListener(this);
}
}

Where setupGUI() queries model for its values as it goes, and duplicates
a certain amount of functionality for updating itself.

I guess it also depends to a certain extent on how your listener
notification mechanism works. i.e. if the event that you receive from
the model already includes the value, you don't need to query the model
for the value, simply bung it into the GUI. Otherwise, you are not
really duplicating the functionality, you are simply calling it in
different circumstances.

e.g.

setupGUI() {
// createTextField
// createCheckBox
getInitialValues();
}

getInitialValues() {
updateTextField();
updateCheckBox();
}

updateTextField() {
textfield.setText(model.getTextValue());
}

updateCheckBox() {
checkbox.setSelected(model.getCheckBoxValue());
}

public update(o, arg) {
if (arg instanceof TextfieldEvent) {
updateTextField();
} else if (arg instanceof CheckBoxEvent) {
updateCheckBox();
}
}

 

[VisionSet]

Two patterns that I've used a lot for this.

Say you have a Model with a state, colour, and which sends
notifyColourChanged().

Version 1) The model, as a matter of contract, will automatically notify any
observers of its colour when it adds them to its listener list:
// in the Model class
addListener(ColourChangeListener listener)
{
listeners.add(listener);
listener.notifyColourChanged();
}

Thankyou, that is obvious isn't it. Code in place and working fine.
One 'cripes' moment. I though I 'd have a cyclic event firing situation.
View components firing events at the model that then fire events back at the
view. But I take it calling setValue on a component doesn't fire an event.