[Mono-list] Windows Forms...wah
Tum
tum@veridicus.com
Sat, 21 Sep 2002 04:52:39 +1200
That's not true. A M-V-C model would mean that the control doesn't
store data at all. The model doesn't have to store data either, it just
needs to produce the data on demand. The data can come from an array or
from a database...the control doesn't need to know about it.
I think people find that you have to write a lot of code in swing
because they are unaware of a lot of the inbuilt classes and end up
writing their own models when they don't need to. Java's anonymous
inner classes allow you to write your own models without explicitly
declaring a type :).
A very simple model list would look something like this:
(note: adhoc code, prolly doesn't compile...)
class ListBox
: Control
{
private IListModel m_Model;
public ListBox(IListModel model)
{
m_Model = model;
m_Model.Changed += new EventHandler(Model_Changed);
}
private void Model_Changed(object sender, EventArgs eventArgs)
{
Invalidate();
}
public override void OnPaint(PaintEventArgs eventArgs)
{
for (int i = 0; i < m_Model.Count; i++)
{
eventArgs.Graphics.DrawString(m_Model.GetItemAt(i).ToString(),
...)
}
}
}
interface IListModel
{
public event EventHandler ListChanged;
public int Count
{
get;
}
public object GetItemAt(int index);
}
class SimpleListModel
{
public event EventHandler ListChanged;
public void FireChanged()
{
if (ListChanged != null)
{
ListChanged(this, EventArgs.Empty);
}
}
public int Count
{
get
{
return 100;
}
}
public object GetItemAt(int index)
{
return index.ToString();
}
}
Using it would be simple:
IListModel myModel = new SimpleListModel();
// Make a list box containing the numbers from 0 to 99
// Notice how there is not an array of size 100 anywhere!
ListBox listBox = new ListBox(myModel);
You could replace myModel with anything. You have to worry about
populating a list/tree/combo ever again. You just need to fire an event
when your data changes, and the list/tree/combo will automagically do
the rest.
The M-V-C pattern actually means less work because you never have to
learn how to use a control beyond it model. Who cares how you
add/remove an item from the listbox anyway? Why would you want to store
data in TWO places? With a model, the list data is retrieved only when
it is needed for repainting. The ListBox never needs to store the data.
This decouples the data from the UI and saves memory.
If you ever need to change the model based on events from the view
(listbox), then you can add a controller.
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.
::Tum
> -----Original Message-----
> From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]
On
> Behalf Of fssc
> Sent: Friday, 20 September 2002 4:01 p.m.
> To: mono-list@ximian.com
> Subject: Re: [Mono-list] Windows Forms...wah
>
>
> When you talk about model/controller classes would implement a list
box
> say
> as two separate entities, one to display the data and another to store
the
> data? If so please don't, or at least give the option to go either
your
> way
> or as they have now. It's all very well bringing in comp sci ideas
like
> this
> but sometimes they just get in the way when you just want a list box
that
> displays, say the days of the week. The last thing one wants to to do
if
> spent time setting up the infrastruture just do some as simple as
that.
> It's
> sometimes much easier to have the 'model' part of the viewer, as it it
in
> most GUI libs, eg VB, VCL, Windows.Forms, and probably others. I tried
> once
> to write a GUI app sing use swing and I was amazed at the amount of
work
> one
> had to do just to get the littlest things to work. After that
expereince I
> gave up and went back to more productive environments.
>
> Be interested to learn what other people things.
>
> Herbert
>
> ----- Original Message -----
> From: "Tum" <tum@veridicus.com>
> To: <mono-list@ximian.com>
> Sent: Friday, September 20, 2002 6:57 AM
> Subject: [Mono-list] Windows Forms...wah
>
>
> > Hi everyone,
> >
> > Here are some of my thoughts on the state of GUIs and Windows Forms.
> >
> > +
> > Windows Forms has very nice native controls. It is fast, responsive
but
> > VERY POORLY designed. It is only a thin layer about native windows
> > controls. Using native controls is *ok*, but they could have at
least
> > used the model-view-controller design pattern. The first thing I did
> > when I started using Windows Forms was to write model/controller
classes
> > for lists and trees.
> >
> > +
> > Swing is wonderfully designed. It is the best and most pure OO UI
class
> > library out there. It used to have major speed problems, but that
> > hasn't been too much of an issue lately.
> >
> > +
> > I really think that instead of porting Windows.Forms (which would be
> > VERY hard), we should be thinking more along the lines of creating
> > something similar to Swing or SWT. A swing like implementation
would be
> > better as you would have more control over component drawing (and
thus
> > better support printing and UI capturing). A designer plugin for
VS.NET
> > can easily be written to support the new toolkit. I think the added
> > bonus of being able to *reliably* port .NET GUI applications to .NET
> > would encourage people to use the new toolkit over Windows.Forms.
> >
> > +
> > If a swing-like toolkit was written, only a few native routines
would be
> > needed. Drawing/blting (System.Drawing?), window creation and
> > message/event dispatching. This would be trivial to implement on
> > Windows and Linux. Most of the UI could then be written in portable
> > managed code :D.
> >
> > ::Tum
> >
> >
> >
> > _______________________________________________
> > Mono-list maillist - Mono-list@ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-list
> >
>
>
>
> _______________________________________________
> Mono-list maillist - Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list