[Mono-list] Windows Forms...wah

[Tum]

::Tum

> -----Original Message-----
> From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]
On
> Behalf Of fssc
> Sent: Saturday, 21 September 2002 3:03 a.m.
> To: mono-list@ximian.com
> Subject: Re: [Mono-list] Windows Forms...wah
> 
> > ListBox listBox = new ListBox(myModel);
> >
> You had to write alot of code to what you wanted to do. Other tools
kits
> have a mixture of models and I think that is a good think. I don't one
> needs
> to write all that in *all* cases.

Uh..!  Most of that code was for implementation of a listbox/model (did
you even read it?).  It was an example of a possible implementation, you
would have to write a lot of code if you had to write the listbox
without M-V-C as well.
If you were to use the listbox, the code would only be a few lines (like
I remonstrated).

> > This, ladies and gentleman this is a good design.  And it has been
> > proven outside of academia (swing, j2ee).  I really hope it will be
used
> > extensively in any Mono UI library.
> >
> 
> It may be good academic design, doesn't mean it's always good in
practice.
> If you're up against the clock on a contract job the last thing you
want
> is
> to start fiddling with model-view controllers. Note that swing is
> not the most popular gui tool kit in the world either. In fact the
mode
> popular gui tools in the world do not use MVC, or other they give you
the
> option.
> 
> I believe that if you confine the mono gui tools to model-view you'll
> loose
> a lot of potential developers.
> 

Bollocks.  You can do stuff the standard way too, with
Model-View-Controller you have choice.


Without MVC:

ListBox listBox = new ListBox();

listBox.Add("1");
listBox.Add("2");
listBox.Add("3");

With MVC:

ListModel model = new ArrayListModel();
ListBox listBox = new ListBox(model);

model.Add("1");
model.Add("2");
model.Add("3");


Wow, one extra line of code to 'emulate' the non-mvc way of doing
things.  I really don't think that's going to lose a lot of potential
developers (and most of them will love the added flexibility).  You will
find that the code complexity of MVC based code actually reduces as the
UI gets more complex.

Lets say you have a listbox that's populated with items that get added,
removed and shuffled all the time.  Would you want to have to mess
around with the listBox's add/remove/clear methods or do you just want
to say to the listbox "hey, I've changed" and have it take care of
everything.

Another advantage of MVC is being able to create multiple views on one
set of data.  From the above example, we could have both a ListBox and
ComboBox display the data from the model.

Without MVC:

ListBox listBox = new ListBox();
ComboBox comboBox = new ComboBox();

listBox.Add("1");
listBox.Add("2");
listBox.Add("3");

// everytime (and anywhere) you change listbox you have to change
combobox

comboBox.Add("1");
comboBox.Add("2");
comboBox.Add("3");


With MVC:

ListModel model = new ArrayListModel();
ListBox listBox = new ListBox(model);
ComboBox comboBox = new ComboBox(model);

model.Add("1");
model.Add("2");
model.Add("3");


With MVC, you never need to know how to use a ComboBox beyond its
constructor.
The data is only stored in one place.  The old way of doing things would
require the list of (1,2,3) to be stored in both the combobox and
listbox.  Having to update both those controls manually every time the
data changes would require much more code (and understanding of the data
manipulation methods ComboBox and ListBox provide).

I think you will lose developers if you don't follow MVC.  You can
easily write default models that copy the old school way of doing
things.  Not using MVC will confine mono (not the other way round).


::Tum