[UI] Well, shall we do something then?

[Bill Schwab]

Jason,

Well said.  I would add the point I already made separately, which is
that the work to connect sub-presenters is different, not in addition
to, what is required in Morphic.

I agree that Morphic can be leveraged for views, and replaced at a later
date if necessary.  Anyone looking for another reason to at least have a
layer on top of Morphic might consider that Morphic is going to get
clobbered (has already been?) in Croquet.  I am not happy about their
reasoning and suspect they will eventually regret the decision; Morphic
could easily suffer for it.

Morphic is certainly not all bad, and in a rewrite scenario, we should
be able to clone (aka steal<g>) quite a lot of code from it, clearly
classifying behavior as belonging to views, interactors (e.g. mouse
tracking) and presenters.  A lot of cruft will be left behind.

Bill







Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bschwab at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029

>>> jason.johnson.081 at gmail.com 09/16/07 8:25 AM >>>
On 9/15/07, Brad Fuller <bradallenfuller at yahoo.com> wrote:
>
> Warning: I know NOTHING about Dolphin. I haven't even seen it. But, as
you
> explain it, it seems like some extra steps to make MVP objects
interactive.
> Morphic objects are by default interactive, with nothing to do to get
there.
> Why would you want a system that makes you perform extra steps?

Because close coupling (and I'm assuming based on what I've read that
Morphic is closely coupled to the models) makes a less flexable
system.

The way I personally program any GUI, web or otherwise, is I make my
model classes.  These are classes that only understand the work to be
done. They know nothing about "does someone need to confirm this?" or
what order their instance variables might be displayed or anything.
You could call these classes in a background process that has no GUI
components at all.

Now, there will be lots of different ways of displaying these model
classes and exposing the services they offer.  It is very often the
case that different people are going to be interested in different
services.  So to support this, the best way I have seen is to have a
"presenter" class that described generically how the class would be
presented to a "third party" if you will [1].

And even a given presentation may have different ways to view it (see
Magritte for examples).

> I agree the event processing in Morphic can be improved. And, from my
small
> experience with it, there are things that need to be fixed. But, why
not put
> energy into improving Morphic? It's already there and MVP seems like a
LOT of
> work!

It will be a lot of work to be sure, but other systems have better
means of doing GUI work right now then Squeak.  It's time to catch up.
 And I am still asking and not hearing (probably my own fault): what
does Morphic offer?  Why bother with the huge clean up it needs?  What
power/flexability does it offer that other graphic systems don't have?

But as has been mentioned by myself and others already, making MVP has
nothing to do with Morphic.  Morphic can make a suitable view for the
MVP framework.

[1] Note that Lukas seemed to arrive at this conclusion independantly
with his Magritte framework that allows you to describe how a model
will be presented, and then it can be viewed via the web, Morphic,
anything that someone has written a "view" for.
_______________________________________________
UI mailing list
UI at lists.squeakfoundation.org
http://lists.squeakfoundation.org/mailman/listinfo/ui