--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> 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
>
I am actively working on this as we speak, actually,
and I'm pleased so far with my results. I actually
have a cut of PH with refactored get and parse
functionality working but I'm seeing other test
failures that I want to get resolved so I know I'm not
breaking anything....
Anyway, I wanted to throw out a few thoughts:
Consumers of the functionality will be pissed if we
break BC. Looking over AntXtras source I see comments
to the effect that PH is broken, so I imagine users
would forgive us if we broke BC to replace something
clearly broken. And, we always have the API not final
comments to fall back on. We _could_ try to preserve
compatibility with the current code by adapting
chained PropertyHelpers to the various subinterfaces
(using reflection to determine which base extension
points have been overridden!?), but that sounds like a
nightmare, frankly. One final observation is that if
we break BC without providing alternate means to
accomplish everything users might already have been
doing (i.e. removing property setting functionality or
allowing only Strings), this is where we could really
annoy people. :) I would not go so far as to say we
will alienate them, only annoy them.
I hope to analyze the current uses of PH in the wild
and possibly start an antlib to provide comparable
functionality in terms of the refactored API.
That said, it wouldn't be the first antlib I've hoped
to start and haven't (yet). :|
-Matt
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo!
FareChase.
http://farechase.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
