[Mono-list] Windows Forms...wah

Tum tum@veridicus.com
Sat, 21 Sep 2002 20:54:29 +1200


> 
> > Well, if it is that disturbing, you could always program the control
to
> > insert and bind to a StringListModel by default.
> >
> > The lack of "simplicity" of having to draw one extra component
(ooooh
> > :P) will be overridden by the fact that you suddenly have a
powerful,
> > flexible new way of populating and synchronizing the list.
> 
> It's not just one extra control, it's one for every component that has
> data.
> Would menu items be modeled using MVC? Would there be a separate model
> control that stored the menu item text? Or would one only use a menu
model
> control when it were necessary? Which controls shouldn't use a MCV
model
> or
> is there not dividing line, or is there a dividing line?
> 

It won't be an extra control.  It'll be an extra component (non UI).  If
you're worried about the memory hit, can I remind you that the MVC model
removes the need to store data twice will actually reduce memory
consumption on large lists, trees etc.

All controls could have models.  You can however configure the default
empty constructor of such controls to create default "vb-like" models.
Java's JButton does this.

No dividing line.  Any control that contains dynamic data should be
designed around a model.  These controls should also provide default
models that work and act like classic controls.

Menus would have models.  If I remember correctly, even MFC menus
supported MVC (the menu items would auto update themselves automatically
based on a bound variable).

> >
> > Do we really want people to use the classic VB technique of using UI
> > components to store data?!  No!  Data should be stored separately
from
> > the UI component.
> >
> 
> It's not just VB, it's most 4gl development kits, including
Windows.Forms,
> Delphi, pretty much most RAD tools as far as I know on Windows? How
are
> 4gls
> on Linux organised?
> 
> Pragmatism is sometimes a necessary 'evil'

That's terrible :(!  I mentioned it because many VBers do it, but there
is no reason to do it!  It is always good programming practise to
separate the UI from data storage no matter what language you use (VB,
C++, C#, etc).

MVC simply wouldn't increase the complexity of doing drag'n'drop style
development.  It even has advantages (like the control deletion/data
loss problem I mentioned earlier).

::Tum - OO Nazi for the day