siguctua at gmail.com
Sun Mar 4 21:16:55 EST 2012
Bill, since you working on it, please consider following.
Models & widgets:
- all widgets which require a model/state, should require a specific
protocol for communicating with them.
- a "real" model object may not support given protocol directly, and
for adapting it, there should be a model/value adaptors.
>From design point of view, it means that widget implementation should
be free of things like we see in PluggableXYZMorph,
which turned into a storage of bunch of selectors and code into
spahetti of UI logic and model logic.
All widgets should just send messages to model in a form:
model perform: myOnClickBigButtonSelector
If there is not possible to connect widget and model directly, we
should provide a model wrappers,
which then could carry those numerous 'myOnClickBigButtonSelector' or
block closures, connectors, whatever.
Like that, a widget designer can clearly tell , what he wants from
widget's model, what inputs his widget expects and rest is not of his
concern. No any
onClickSelector ifNil: [ yadda yadda ] ifNotNil: [ (model undestands:
onClickSelector ) ifTrue: [ model perform: onClickSelector ] ]....
this should be replaced by appropriate model adaptors, value holders
etc , so widget may keep own code clean.
We had discussions before, like why don't use blocks instead of
selectors. And the answer was that it is easier to find
with symbols than blocks.. Which is true. Unless model(s) could have a
built-in support for navigating and finding real guy behind the
scenes, who responsible
for taking actions etc.
And i think this is much more appropriate than manually traverse
through the hashes of selectors from a button nested into multiple
levels of widgets,
and models connected /nested in hierarchy too..
About layouts and layouts managers.
It's kind of fine to have proportional layouts, but it doesn't solves
all needs. Sometimes we want to "put it here" and "i don't give a shit
I dealt with nested layout since Delphi, and while they serve well
most of the times, sometimes it is very hard to convince designed that
is not really fits into out technical world, simply because you
cannout "put it here" and designer "don't give a shit about layouts".
So, people invented workarounds, like in modern browsers we have
absolute/fixed/relative positioning and z-levels aka layers.
Another approach is to control layout via anchors. I did some
experiments with it not long ago, and i think it is quite promising,
except that more thought needed how to organically merge this with
Anyways, here the link to original discussion:
(and somewhere there must be the code)
On 5 February 2012 04:25, Schwab,Wilhelm K <bschwab at anest.ufl.edu> wrote:
> I'm still a little overwhelmed, but I see attention to layout; this has been
> a BIG stumbling block for me in my efforts to bring MVP to Pharo. I
> recommend using nested composite view/presenter pairs for most layout.
> First, it lends itself well to an eventual view editor, and second, can be
> surprisingly easy to code directly.
> Each composite view has a layout manager. Layouts include constrained
> table-like elements, but the real workhorses are proportional layouts, which
> can be set either horizontal or vertical. By nesting them, very complicate
> behavior can be achieved.
> There, said "nesting," and that has been where I have fallen into trouble.
> Pharo/morphic layout works great for children of the top level, but after
> that, I can't get reliable results.
> Sleep calls...
> From: pharo-project-bounces at lists.gforge.inria.fr
> [pharo-project-bounces at lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K
> [bschwab at anest.ufl.edu]
> Sent: Saturday, February 04, 2012 6:36 PM
> To: pharo-project at lists.gforge.inria.fr
> Subject: [Pharo-project] MVP
> Hello all,
> I have been to busy to read today, but I like seeing any discussion of
> MVP. I am **slowly** working on a framework for it, but would be glad to
> be beaten to it.
> Default models are key; they must be replaceable, but (sub)triads should
> work "out of the box." Models can include value holders, value adapters,
> converters, and contexts, depending on how they are wired.
> I have something of a start on the adapters and converters, which I can try
> to package and make available. If nothing else, they will have value in
> seeding discussion if not be directly usable. More to come.
More information about the Pharo-dev