On 6/15/07, Peter Reilly <[EMAIL PROTECTED]> wrote:
> I don't get the Set part. How would that be used? The GetPR comes into
> play in a ${scheme:...} expansion, but how would the SetPR work? --DD
Thanks for the example Peter. That's what I was waiting for.
There could be a number of uses for example:
<mm:bean id="abc" class="org.example.MyBean">
<attributes version="a" color="blue" count="10"/>
</mm:bean>
Hmm, I notice you've used an id, so we have a reference here ;-)
<addpropertyresolver classname="org.example.BeanPropertyResolver"
prefix="bean" (?) />
So far, so good, although I'd like to be able to have an antlib with a
single property resolver, and have the prefix used for that antlib
automatically be used as the custom PH prefix. In other words, I want
to auto-magic xmlns:bean="antlib:..." to reserve the PH prefix bean
for my PH (possibly even if the antlib doesn't declare one. Otherwise
would could have a XML NS prefix mapping to an antlib, and a PH prefix
mapping to something coming from elsewhere, which is confusing.)
<property name="bean:abc.count" value="20"/>
This is what I don't like... Property names have currently no "rules"
as far as syntax, so first of all this is not BC, and we're talking BC
at the build file level, not the API level, the former being even more
important. And second of all, this would be better handled by a custom
task, like <bean:assign refid="abc" value="20" />.
So I contend that assignment (your SetPH) is better done in custom
ways, using custom tasks, which is then completely BC.
<ac:if>
<equals arg1="bean:abc.count" arg2="20"/>
<then>
<echo>Set the bean value property successfully!</echo>
</then>
</ac:if>
Here OTOH its an read access, a bit in disguise since the ${} is
implicit in this context, and I'm all for it! The reason we need this
is that you can't use a task in the particular context, thus the
syntax extension to access *String* only *values* of *something*,
which can be a pure property (string,string key/value pair) and an
arbitrary *object* which can be resolved using a scheme/PH-specific
*key* string.
So I still don't buy SetPH ;-)
And just like Stefan, let me finish that I'm also in favor of fixing /
enhancing / redoing PH, or whatever is necessary, but only to extend
the property dereference syntax (read access).
Overloading the meaning of <property> for write access to arbitrary
"things" is not a good idea IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
