MVP - presenters as factories; some models; CODE!!!

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

MVP - presenters as factories; some models; CODE!!!

Schwab,Wilhelm K
Hello all,

I am a strong believer in "say it once," and I find Polymorph's lists, and especially trees, very cumbersome to use.   One is led to create a slot to hold selections and accessors.  That work should be done by by a reusable presenter with some help from ListModel and TreeModel.

Attached is the current state (of confusion) of the framework.  The factory concept (presenters create morph-model pairs, the views are all morphs) is new, in some sense a concession to reality.  I would prefer other layout means (see the various "obsolete" parts of the package), but have not been able to make them work.  Using polymorph rows and columns, I can get close enough to what I need, at least with a suitable user base.

The GUI is nothing special, but the way it is built is, I think, worthy of some attention.

Try

   CartoonPersonalityBrowser new asMorph openInWorld.

for a few laughs.  For those not familiar with it, the Rocky and Bullwinkle Show was *not* for kids.  Kids will enjoy it, but it was in fact beautiful cold-war satire.  The road runner and coyote are more likely to be familiar to you, and are just good (great) slapstick with a few comments on life (everything works fine until the roadrunner appears...).

The list and tree scream for a #selectionChanging: event, which I had not appreciated until I created the above example.  In short, you can edit the fields, but they are not saved.  Punching the presenters onto the tree elements would be a little tricky, but one should be able to know that the selection is changing, react to it (saving current contents) and then even veto the change.  More work...

Please comment freely.

Bill





Dolphin-MVP-BillSchwab.2.mcz (62K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: MVP - presenters as factories; some models; CODE!!!

Schwab,Wilhelm K
I was playing with a workbench that I built for a long-standing project with LOTS of data, and realized that I was leaving a trail of realized (read chewing up a lot of memory) objects as I tinkered.  That underscored the need for #selectionChanging: on trees and lists.  The attached appears to successfully add same, though it has not had much testing.

Try the cartoon example.  You should now be able to edit the fields and see the results of the change the next time you visit the character.  For example, Bullwinkle's IQ is listed as low.  You might want to change that to VERY LOW :)  Try it.

Bill



From: [hidden email] [[hidden email]] on behalf of Schwab,Wilhelm K [[hidden email]]
Sent: Monday, March 19, 2012 9:44 PM
To: [hidden email]
Subject: [Pharo-project] MVP - presenters as factories; some models; CODE!!!

Hello all,

I am a strong believer in "say it once," and I find Polymorph's lists, and especially trees, very cumbersome to use.   One is led to create a slot to hold selections and accessors.  That work should be done by by a reusable presenter with some help from ListModel and TreeModel.

Attached is the current state (of confusion) of the framework.  The factory concept (presenters create morph-model pairs, the views are all morphs) is new, in some sense a concession to reality.  I would prefer other layout means (see the various "obsolete" parts of the package), but have not been able to make them work.  Using polymorph rows and columns, I can get close enough to what I need, at least with a suitable user base.

The GUI is nothing special, but the way it is built is, I think, worthy of some attention.

Try

   CartoonPersonalityBrowser new asMorph openInWorld.

for a few laughs.  For those not familiar with it, the Rocky and Bullwinkle Show was *not* for kids.  Kids will enjoy it, but it was in fact beautiful cold-war satire.  The road runner and coyote are more likely to be familiar to you, and are just good (great) slapstick with a few comments on life (everything works fine until the roadrunner appears...).

The list and tree scream for a #selectionChanging: event, which I had not appreciated until I created the above example.  In short, you can edit the fields, but they are not saved.  Punching the presenters onto the tree elements would be a little tricky, but one should be able to know that the selection is changing, react to it (saving current contents) and then even veto the change.  More work...

Please comment freely.

Bill





Dolphin-MVP-BillSchwab.3.mcz (63K) Download Attachment