You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by D&J Gredler <dj...@gmail.com> on 2007/02/23 00:16:24 UTC

T5: List -> SelectModel Coercion

Hi,

I need a List -> SelectModel coercion for a sample app I'm building, and was
thinking of contributing a patch. I'm wondering which would be the most
desirable implementation:

1. List -> SelectModel
2. List -> Map
3. Collection -> SelectModel
4. Collection -> Map

The reason I thought it might be better to use a Collection as the source
was that it would take care of Sets and Queues, too. However, I don't know
if that would mess up the existing Map -> SelectModel coercion.

The reason I thought it might be better to use a Map as the target is that
the coercion might then be useful outside of this use case.

Daniel

Re: T5: List -> SelectModel Coercion

Posted by D&J Gredler <dj...@gmail.com>.
The labels and values are both String.valueOf(listElement), where
listElement is usually going to be a String, but allows any Object.


On 2/23/07, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> I think List to SelectModel would make the most sense because a
> SelectModel does need a particular ordering of the OptionModels it
> contains.  Set doesn't give any sense of order.
>
> How are you handling this in a generic way?  How do you determine what
> the labels and client-side values are?
>
>
> On 2/22/07, D&J Gredler <dj...@gmail.com> wrote:
> > Hi,
> >
> > I need a List -> SelectModel coercion for a sample app I'm building, and
> was
> > thinking of contributing a patch. I'm wondering which would be the most
> > desirable implementation:
> >
> > 1. List -> SelectModel
> > 2. List -> Map
> > 3. Collection -> SelectModel
> > 4. Collection -> Map
> >
> > The reason I thought it might be better to use a Collection as the
> source
> > was that it would take care of Sets and Queues, too. However, I don't
> know
> > if that would mess up the existing Map -> SelectModel coercion.
> >
> > The reason I thought it might be better to use a Map as the target is
> that
> > the coercion might then be useful outside of this use case.
> >
> > Daniel
> >
>
>
> --
> Howard M. Lewis Ship
> TWD Consulting, Inc.
> Independent J2EE / Open-Source Java Consultant
> Creator and PMC Chair, Apache Tapestry
> Creator, Apache HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work.  http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>

Re: T5: List -> SelectModel Coercion

Posted by Howard Lewis Ship <hl...@gmail.com>.
I think List to SelectModel would make the most sense because a
SelectModel does need a particular ordering of the OptionModels it
contains.  Set doesn't give any sense of order.

How are you handling this in a generic way?  How do you determine what
the labels and client-side values are?


On 2/22/07, D&J Gredler <dj...@gmail.com> wrote:
> Hi,
>
> I need a List -> SelectModel coercion for a sample app I'm building, and was
> thinking of contributing a patch. I'm wondering which would be the most
> desirable implementation:
>
> 1. List -> SelectModel
> 2. List -> Map
> 3. Collection -> SelectModel
> 4. Collection -> Map
>
> The reason I thought it might be better to use a Collection as the source
> was that it would take care of Sets and Queues, too. However, I don't know
> if that would mess up the existing Map -> SelectModel coercion.
>
> The reason I thought it might be better to use a Map as the target is that
> the coercion might then be useful outside of this use case.
>
> Daniel
>


-- 
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org