Why is the ListPresenter so primitive?

I am going through the Ted B. book and have hit the bit where instead
of using Radio buttons for gender you use a list.

I don't understand why the ListPresenter is so primitive? Why do I need
to do the when: #selectionChanged  stuff?

Have I missed someting? I was expecting to create a presenter where I
told it the collection of items to display (either as an aspect on some
model or specifying the list directly) and more importantly, what
aspect on my model the selection changing would update?

It really seems like many of these things are primitive from an age
gone by?

Is there something already in place or am I right in thingking that I
if I want something more advanced (actually simpler) then I should
implement it myself.

Ti,

Tim,

> Have I missed someting? I was expecting to create a presenter where I
> told it the collection of items to display (either as an aspect on some
> model or specifying the list directly) and more importantly, what
> aspect on my model the selection changing would update?

What part of a model should reflect the user's current selection(s) ?  That's a
purely presentation layer concept -- on a par with which sub-pane of a window
currently has focus.

It sounds as if you want to think of lists in a completely different way --
where the list itself is secondary, and the current selection is the important
thing.  Where the selection is the "value" of the component and the list is
merely a presentation-level concept (giving the user another way of entering a
value).

If so, then that's fair enough, but it's not how ListPresenter (or the other
list/tree things) are designed to work in Dolphin.

It sounds pretty trivial to create a new kind of ValuePresenter which does work
that way -- and indeed, it seems that the work has been done for you.  See
ChoicePresenter ;-)

    -- chris

Tim,

It's interesting, when we were originally designing the framework the
original ListPresenter actually had two models: the first was the list
(as we have now) and the second was a ValueModel which held the
selection. We actually dropped this idea because we thought the idea of
having more than one model associated with an MVP triad would actually
be more confusing.

I've always thought that there are three numbers associated with
"cleanness" in computing, zero, one and infinity. Following that rule
it was my opinion that we should either have no models, one model or
any number of models associated with any MVP component. So at one point
we did consider having every aspect of a presenter being implemented by
a ValueModel. This would have allowed the "wiring up" of components
(PARTS style) but we felt that, certainly on the hardware of the day,
this would be to onerous.

Anyway, that's the reason why it's like it is so I'm sorry if it seems
primitive. As Chris pointed out it wouldn't take much to implement a
derived class which does what you want.

(oh, BTW, I take it you have looked at ChoicePresenter and confirmed
that that doesn't do what you're looking for).

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Hi Andy/Chris

> Anyway, that's the reason why it's like it is so I'm sorry if it seems
> primitive. As Chris pointed out it wouldn't take much to implement a
> derived class which does what you want.
>
> (oh, BTW, I take it you have looked at ChoicePresenter and confirmed
> that that doesn't do what you're looking for).

As I grope through some of the background (I think this is what Joseph and
the other muscians call doing the atudes) I know that I am missing things,
so I will certainly look at Choice presenter (it sounds promising) - and
I dimly recall reading about it and didn't immediately notice it as I went
"off piste" from the the Ted book.

However I think its interesting that to me most of the "#when:send:" options
are very old fashioned and when I look for more modern equivalents (which
MVP is supposed to be) I keep falling flat. (and I concurr that some rare
things will need it)

My first attempt at creating a list presenter that dealt with a selectionChanged
fell flat as onChanged doesn't appear to tell me the new value that has been
changed to (so my special list model was a flop, and it looks like yet more
work, adding a new presenter to deal with a new list model).

So maybe I think in a wierd way - but this is the second attempt at creating
a gui that has now resulted in me thinking differently from the framework
(the first being one that Chris helped me with were my UI wanted to edit
a model attribute that also affected the range of a ProgressBar view).

The joy is that their are always workarounds - but its a bit jarring that
seemingly intuitive (at least to me) things aren't out of the box.

Tim

Andy/Chris

>> (oh, BTW, I take it you have looked at ChoicePresenter and confirmed
>> that that doesn't do what you're looking for).

After all that experimentation (which taught me quite a bit) -
ChoicePresenter is exactly what I wanted - it treats the selected item
as an aspect of your model.

It was actually very interesting and instructive to look at its
implementation to see how I got mine wrong - I thought I had a handle
on presenters but their are subtleties that I forgot (I guess it just
comes from experience).

The main thing I forgot was that a presenter (just like the dialogs I
have been building) has createSchematic wiring and so you can register
a selection changed with the view at the correct time (seems obvious
now - but I didn't do that for some strange reason).

Thanks for the tip guys,

Tim

p.s. Andy I will try and reproduce some of the other things I hit when
I get a few spare moments with both of my machines.

Tim,

[about ChoicePresenter]
> It was actually very interesting and instructive to look at its
> implementation [...]

One (other?) interesting thing about ChoicePresenter is that its View Resources
are about the same as ListPresenters -- so it's an example where two fairly
different Presenters make use of the same kind of View.

    -- chris

Tim,

> However I think its interesting that to me most of the "#when:send:"
> options are very old fashioned and when I look for more modern
> equivalents (which
> MVP is supposed to be) I keep falling flat. (and I concurr that some rare
> things will need it)

Why do you see the event triggering system as old fashioned ?  Or maybe its the
way the system is applied in the MVP implementation ?

FWIW, I use events directly, and with never a thought.  I rarely use the
ValueModels, and related "short-cuts" for a number of reasons -- chief amongst
which is that I don't think they same time or effort in many cases, and I'd
rather not have a mix of two approaches in my code.  YMMV...

    -- chris