PropertySelection Feature Request (Discuss)

[Eric Everman <ev...@precedadesign.com>]

What do people think about add a zero argument constructor and a set 
method to StringPropertySelectionModel so that it can be created via 
the <bean> tag in the .page file?

I currently use a StringPropertySelectionModel in the page's base class 
to provide the model, but this seems a bit inelegant to me.  Perhaps 
its just me, but it seems like the page's base class should be reserved 
for actions.  Static data, on the other hand, can be more cleanly 
placed in an xml file - like the .page file.

Thoughts?

Eric Everman


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

Re: PropertySelection Feature Request (Discuss)

[Paul Ferraro <pm...@columbia.edu>]

I'd be in favor of that.  The default constructor should initialize the 
interal String[] to an empty (i.e. size 0) one.

Paul

Eric Everman wrote:

> What do people think about add a zero argument constructor and a set 
> method to StringPropertySelectionModel so that it can be created via 
> the <bean> tag in the .page file?
>
> I currently use a StringPropertySelectionModel in the page's base 
> class to provide the model, but this seems a bit inelegant to me.  
> Perhaps its just me, but it seems like the page's base class should be 
> reserved for actions.  Static data, on the other hand, can be more 
> cleanly placed in an xml file - like the .page file.
>
> Thoughts?
>
> Eric Everman
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>


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