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.
