On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
> Nope. We have several things the provide dynamic menus:
I'm glad that the menu model in LyX is more complete than I thought.
Congratulations on some good work there.
Therefore, I must retract the argument that GUII will make the model more
basic, since obviously it isn't for the dialogs and the menus.
> Asger> Also, you do not have the infrastructure to handle changing
> Asger> toolbars on the fly.
>
> Having the infrastructure would be easy. The most difficult part is
> probably to implement that in the xforms frontend.
If you by infrastructure mean the model abstraction, yes, this will be
easy. But once again, you basically just shove complexity into the
front-ends: Each front-end has to implement the rest.
> I won't comment on MVC, since it's been something I'm very fuzzy
> about.
Fair enough.
Here's a section from the book "Design Patterns" that explains the MVC
concept:
"1.2 Design Patterns in Smalltalk MVC
The Model/View/Controller (MVC) triad of classes is used to build user
interfaces in Smalltalk-80. Looking at the design patterns inside MVC
should help you see what we mean by the term "pattern."
MVC consists of three kinds of objects. The Model is the application
object, the View is its screen representation, and the Controller defines
the way the user interface reacts to user input. Before MVC, user
interface designs tended to lump these objects together. MVC decouples
them to increase flexibility and reuse.
MVC decouples views and models by establishing a subscribe/notify protocol
between them. A view must ensure that its appearance reflects the state of
the model. Whenever the Model's data changes, the model notifies views
that depend on it. In responce, each view gets an oppurtunity to update
itself. This approach lets you attach multiple views to a model to provide
different presentations. You can also create new views for a model without
rewriting it.
(I omit an example of this, an explanation of how MVC is applicable in
other contexts, and another example of how Model/VIew separate is useful
to enable nesting of views into a composed view.)
MVC also lets you change the way a view responds to user input without
changing its visual presentation. You might want to change the way it
responds to the keyboard, for example, or have it use a pop-up menu
instead of command keys. MVC encapsulates the response mechanism in a
Controller object. There is a class hierarchy of controllers, making it
easy to create a new controller as a variation on an existing one.
A view uses an instance of a Controller subclass to implement a particular
response strategy; to implement a different strategy, simply replace the
instance with a different kind of controller. It's even possible to change
a view's controller at run-time to let the view change the way it responds
to user input. For example, a view can be disabled so that it doesn't
accept input simply by givint it a controller that ignores input events.
(More details of which Design Patterns are used in a MVC separations)
"
Now I think you can see what I mean: The task of separating the view and
controller from a combined ViewController is not done in the GUII effort.
That is acceptable, because the model/viewcontroller separation is the
most important separation. The view/controller separation is not as
crucial for a clean program.
But I must point it out to you: By doing GUII, you will not be doing the
refactoring of separation the view/controller part at first, because that
is too hard.
When that is said, Allan did manage to separate some policy out in the
dialog GUII job: The button policy classes represents a control component
in a view/controller separation.
Summing up:
At this point, you have a clean separation of Model/View/Control in a GUII
fashion for the dialogs.
You have a clean separation of Model/ViewController for the menus. This
framework is suboptimally implemented for XForms only.
What you don't have:
1) A separation of view and control for the menus
2) A separation of M/VC for the toolbar
2b) A separation of V/C for the toolbar
3) A separation of M/VC for the canvas
3b) A separation of V/C for the canvas
1) is what I argue is hard. Therefore, you probably won't do it, and just
leave each frontend as an integrated VC pair.
2) is relatively easy. You are already discussing it on the list at the
moment.
2b) is hard. Therefore you probably won't do it, but just leave each
front-end as an integrated VC pair.
3) is hard. Some work has been started to get a View abstraction (the
painter).
3b) is also hard, and will probably never be done in a GUII setting.
If you focused on one front-end only, the tasks of 1), 2b) and 3b) would
be easier.
So in conclusion, you have been making great progression in the GUII
job. In particular, you have demonstrated that it is possible to
develop the model components without dumbing them down.
But there still is a long way to go, and by chosing this direction,
you more or less deliberately decide that the view/controller separation
is not necessary for the first round.
That certainly is a viable path, and I encourage you to continue on it,
given that there is no interest in focusing on a one front-end solution
which arguably could progress faster.
Greets,
Asger
