Ron Piterman wrote:
2) the "take an object *source* (binding) and edit it" approach.
Tapestry form components use the second - they read an write to
sources (properties) instead of manipulating the values.
You probably want to take that same second approach ( am I right here? )
Yes you're right. I want to be able to edit arbirtrary sections of my
object graph using the binding system.
you want your component to get the clients' address *source* and if
its empty set it.
Exactly.
what about this:
<parameter name="address" property="addressParameter"/>
I'm using annotations, though I guess that can be done with that.
now in the component code you don't use the parameter directly but
abother method:
public Address getAddress() {
Address a = getAddressParameter();
if (a == null) {
a = createNewAddress();
IBinding binding = getBinding("address"); // am not certain its the
// right syntax here
binding.setValue(a);
}
return a;
}
now this way, the first component which accesses the clients address
will initialize it and set it back to the client.
That'd be:
public Address getAddress() {
Address a = getAddressParameter();
if (a == null) {
a = createNewAddress();
setAddressParameter(a);
}
return a;
}
But it doesn't work for @Persist bindings, since rendering has already
begun.
(hahaha, yes. I tried it all. Don't even mention @InvokeListener!)
--
Ing. Leonardo Quijano Vincenzi
Director Técnico
DTQ Software
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
