Q regarding the model in ChoicePresenter / ChoicePrompter

I'd like to write an OrderedChoicePresenter that  allows the multiple
choice of items in cases, where the order is of relevance, i.e. to
choose list columns to display or multiple sort fields.

I'll probably represent it in a view by having a list of available
choices and another list that contains the selected choices together
with buttons to add or remove choices and change the order of chosen items.

Eventually I'd also like to use that presenter as component in a
composite presenter that also allows the editing of certain attributes
of the items themselves, i.e. to specify ascending/descending sort order
for sort fields or column width for list columns.

Keeping these planned extensions in mind, I figured that the model for
the OrderedChoicePresenter would be a class consisting of a collection
of items and a sequencable collection representing the choices of items.
That model could then also be used by presenters that use the
OrderedChoicePresenter as a component.

When I browsed through the Dolphin image, I expected the ChoicePresenter
and ChoicePrompter classes to have a similar model, but noticed that the
choices were not part of the model, only the chosen items were and that
the choices were set by a separate method.

Is this just a convenience to avoid defining a special model class or is
this a design feature that I also should consider? If I should consider
it, would it only be relevant in cases, where the choices themselves are
not editable (as in ChoicePresenter and my planned
OrderedChoicePresenter), or is this a more general pattern?

Right now I am just a bit confused as to how to approch the design of my
model.

Bernhard

Bernhard,

> Right now I am just a bit confused as to how to approch the design of my
> model.

I hesitate to claim that I know how to solve your problem.  Presenting
collections always seems to involve choosing the lesser of evils, more
so than other common problems.  I will defer to OA on why the various
presenters work the way they do.  One observation though, is that
ChoicePresenter has come a _long_ way in useability and flexibility;
they were a pain to work with in the early days.  Most of the
improvement seems to center on additional control over identity/equality
via search policies.

Probably not relevant to your project, I wrote helper methods to set
search policies in the view and presenter.  I also found need for
#choices:value: to set the choices and value of a choice presenter.  You
are welcome to them if you are interested.

Finally, you might look at my Pane Holders package, and PaneChooser in
particular.  Also, CodeGenerator's constructor dialog might give you
some ideas, though it really just bounces items between two lists, one
selected, one not.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

Thanks so much for your feedback. At this point in time I wasn't even
aware of any issues with search policies, but I'll keep that in mind.

I'll definitely take a look at your Pane Holders and CodeGenerators
examples.

Thanks again,
Bernhard

Bill Schwab wrote: