ListModel observer on its listitems?

Hi,

can a listmodel be set to be an events observer of its items?

Maybe in a similar fashion like a set with a sortBlock:?

Like when an item is added send

ListModel add: anItem
        anItem when:#someEvent send:#updateItem: to: self "ListModel" with: anItem

....


and:


ListModel removeItem: anItem

        anItem removeEventsTriggeredFor: self


Günther

On Mon, 17 Jan 2005 10:42:25 +0100, Günther Schmidt <[hidden email]>  
wrote:

> can a listmodel be set to be an events observer of its items?
>
> Maybe in a similar fashion like a set with a sortBlock:?
>
> Like when an item is added send
>
> ListModel add: anItem
> anItem when:#someEvent send:#updateItem: to: self "ListModel" with:  
> anItem

> and:
>
>
> ListModel removeItem: anItem
>
> anItem removeEventsTriggeredFor: self

Why do you want to do this?

--
Regards
HweeBoon
MotionObj

Yar Hwee Boon schrieb:
A listmodel is usually attached to a listPresenter, and the
listpresenter receives update events from the listmodel, when the *list*
changes, ie. when items are added or removed, but not when an item is
updated.
At least not for all that I've been able to figure sofar.

In the personalmoney application this problem doesn't occur, because
when a transaction gets updated, it is temporarily removed from the
list, which triggers the first update event to the listpresenter, and
then reinserted into the list, which triggers the second update event
for the list presenter.

In other words, the model (the list of transactions in this case) is
altered mereley for the purpose of updating the view, and I'm just not
sure I want to do it this way.


Günther

On Mon, 17 Jan 2005 11:11:36 +0100, Günther Schmidt <[hidden email]>  
wrote:

>> <[hidden email]>  wrote:

>>> ListModel add: anItem
>>>     anItem when:#someEvent send:#updateItem: to: self "ListModel"  
>>> with:  anItem

You can certainly try that. Anyway, this is relatively simple to try, just  
test it without saving your image. Anyway, I don't see why it would not  
work.

> In the personalmoney application this problem doesn't occur, because  
> when a transaction gets updated, it is temporarily removed from the  
> list, which triggers the first update event to the listpresenter, and  
> then reinserted into the list, which triggers the second update event  
> for the list presenter.

I'm not sure how the others do it, but what I do instead is, in this  
situation, eg. you call up a dialog to allow the user to edit the object.  
I then send #updateItem: after the dialog is closed or when it is closed.

--
Regards
HweeBoon
MotionObj

Günther Schmidt wrote:

> Like when an item is added send
>
> ListModel add: anItem
> anItem when:#someEvent send:#updateItem: to: self "ListModel" with: anItem

You can do that, but I wouldn't want to change the system to do it by default.

The reason is that setting up an observer is not free (by default every
observable/observer pair ends up with an entry in the _EventsRegister) and so
using a ListModel on a list of, say, ten thousand entries would be quite
expensive.  It also isn't often needed since there is usually only a small
number of ways that the items can be modified, and it is relatively easy for
the modifying code to trigger the necessary change notifications.

That isn't always the case, though -- it can sometimes make the application
logic quite awkward (and this is especially true of trees, where I have yet to
find a satisfactory general solution).  In such cases, it seems like a
reasonable idea to consider using your own subclass of ListModel that does
Observe its elements.  If you do that (and your lists are fairly large) then
you may want to consider making your items be a subclass of Model, since that
has an optimised form of the event triggering mechanism, or of copying the
Model #getEvent (etc) code into your item class(es).

    -- chris