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" <[email protected]> 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.
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
