Just to clarify some more...
I built a AbstractPropertySelectionModel implementing
IPropertySelectionModel. A Method like
getAddressPropertySelectionModel() returns an anonomyous subclass to the
PropertySelection component. Its constructor parameter is the List of
objects that will become the options. It is necessary for the subclass
used by a particular component to over-ride the abstract methods
getValue and getLabel. I think this is just about what Erik has done.
What I don't like about this is that changing the property for value or
label, something the web designer could do in half a second, now also
requires the developer, a process about 10,000 times more expensive than
it needs to be.
What I wanted was to be able to build and change this model on the page
specification either as a bean or another component. Erik's use of
'value path expression' sound's like the right direction because list,
value and label should all be ognl expressions similar to the
contrib:table use of row.id. And if we really got going the PS
component *could* simply take a ognl list, value, label.
I think I fell off the boat trying to conceptualize matching a indexed
property to the option object with an ognl expression to one of its
properties. Would looking at TableRow give me the clue I am missing?
Erik Hatcher wrote:
Just to clarify Paul's response a bit as it did not seem clear on
this... you can create a single custom IPropertySelectionModel class
to handle a wide range of data. In the past, I've created a general
purpose (within the scope of a particular project) JavaBean model
that allowed specification of the name path expression and value path
expression.
I'm pretty sure if you check the list archives for
IPropertySelectionModel you'll find several examples of this sort of
thing.
Erik
On Jun 4, 2005, at 12:43 AM, Paul Ferraro wrote:
Yes (assuming that they contain different data), but your
IPropertySelectionModel should ideally present a "view" of your
collection - so you should easily be able to create a implementation
class to handle each type of collection.
Paul
Vinicius Carvalho wrote:
Well, once again I'm confused. Must I have one model for each
collection? What happens if I have dozens of collections that comes
from the Database?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: tapestry-user- [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
