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...

Bill

From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Schwab,Wilhelm K [bschwab@anest.ufl.edu]
Sent: Saturday, February 04, 2012 6:36 PM
To: pharo-project@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.

Bill