What is the idea behind the #displayBlock: in DropListModel? I expected it to be something that is stored in the DropListModel and re-evaluated each time the items change. But from the implementation I get that this is a one-time action.
It's a bit weird. Sean and I should do another pass on this, because it's far too disturbing now Ben On Sep 20, 2013, at 11:34 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
What is the idea behind the #displayBlock: in DropListModel?
I expected it to be something that is stored in the DropListModel and re-evaluated each time the items change. But from the implementation I get that this is a one-time action.
On 2013-09-20, at 18:44, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
It's a bit weird.
Sean and I should do another pass on this, because it's far too disturbing now
haha, ok, well I got it's easy to get it working the other way around ;), but yeah slightly counter intuitive. Second question: How can I display a morph in the dropdown list? (aka icon + label).
Camillo Bruni-3 wrote
What is the idea behind the #displayBlock: in DropListModel?
The original drop list required manual building of DropListItems, which chop the original domain objects down to maps of label strings, to action blocks. There seem to be two general use cases for drop down lists: 1. Heterogeneous items like { { 'Open a workspace' -> [ Workspace open ] }. { 'Save the image' -> [ ... ] }. Here the original implementation "works", but at the cost of forcing the user to know about and build DropListItems 2. Related items like displaying class names and returning the actual class that's selected. I never liked the way this was handled by the original implementation, but it became more jarring under Spec because other list model classes (like ListComposableModel) use #displayBlock: to adapt domain objects to list labels So the intention was two-fold: 1. to provide an API through DropListModel that hides the Items 2. to make Spec's list handling more uniform So the situation is improved for both use cases: items := { DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock }. listModel items: items. For 1 becomes: listModel addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock. For 2 becomes: listModel items: aCollectionOfDomainObjects; displayBlock: [ :domainObject | ... ]. Where #2 uses the same API as ListComposableModel. But something doesn't feel quite right about the current implementation, so let's def do another pass. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Question-DropListModel-tp4709441p4709503.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
thanks for the details, here are my requests, which as usual I expected to be implemented by yesterday :P. Well mostly for synchronizing and to see if my idea fits with what you thought about it. - First of all we should get the API straight, it is not clear what returns the internal model (DropListItem) and what returns the externally injected model. - I am missing icons :P - a lazy labelBlock and a lazy iconBlock - convenience label and icon block creators which internally set the labelBlock and iconBlock: iconProperty: #icon, labelProperty: #packageName So what I expected somehow (coming from Flex / Flash, yes you read correctly flash!): - items: { myObject1. myObject2...} - labelBlock: [ :item :dropListItem "optional" | item asString ] - iconBlock: [ :item :dropListItem "optional" | item isClosed ifTrue: [ Smalltalk ui icons closedIcon ] ifFalse: [ Smalltalk ui icons openedIcon ]] => by default you get the icon/label from the internal DropListItem => if the icon / label is not set, use the #labelBlock or #iconBLock on the DropList => if there is no #labelBlock use `asStringLimitedTo: 100` => if there is no #iconBlock do not use an icon By default in Flex you cannot access the internal wrapper (DropListItem in our case) hence you have to defined the accessors for the label and icon directly on your own model (here myObject). This prevents you from the non-uniform lists you described below and only marginally simplifies the design (and dare you having a look at their implementation :P). On 2013-09-21, at 10:10, "Sean P. DeNigris" <sean@clipperadams.com> wrote:
Camillo Bruni-3 wrote
What is the idea behind the #displayBlock: in DropListModel?
The original drop list required manual building of DropListItems, which chop the original domain objects down to maps of label strings, to action blocks.
There seem to be two general use cases for drop down lists: 1. Heterogeneous items like { { 'Open a workspace' -> [ Workspace open ] }. { 'Save the image' -> [ ... ] }. Here the original implementation "works", but at the cost of forcing the user to know about and build DropListItems 2. Related items like displaying class names and returning the actual class that's selected. I never liked the way this was handled by the original implementation, but it became more jarring under Spec because other list model classes (like ListComposableModel) use #displayBlock: to adapt domain objects to list labels
So the intention was two-fold: 1. to provide an API through DropListModel that hides the Items 2. to make Spec's list handling more uniform
So the situation is improved for both use cases: items := { DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock. DropListItem named: aString do: aBlock }. listModel items: items.
For 1 becomes: listModel addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock; addItemLabeled: aString do: aBlock. For 2 becomes: listModel items: aCollectionOfDomainObjects; displayBlock: [ :domainObject | ... ].
Where #2 uses the same API as ListComposableModel.
But something doesn't feel quite right about the current implementation, so let's def do another pass.
----- Cheers, Sean -- View this message in context: http://forum.world.st/Spec-Question-DropListModel-tp4709441p4709503.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (3)
-
Benjamin -
Camillo Bruni -
Sean P. DeNigris