no, not static. I think you are not seeing that an object associated
with an <option/> has multiple properties and the designer may need to
choose, say SSN at one time and last name on another -- different
properties identifying the same collection of domain objects.
Paul Ferraro wrote:
If you expect your web designer to be able to change option
labels/values then I take it your values are static and not database
driven...
If that's the case, why not use the Select and Option components?
Paul
euphobot wrote:
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]
---------------------------------------------------------------------
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]
