ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Reilly" <peter.kitt.rei...@gmail.com>
Subject Re: PropertyHelper thoughts
Date Fri, 15 Jun 2007 16:27:03 GMT
On 6/15/07, Matt Benson <gudnabrsam@yahoo.com> wrote:
>
> --- Dominique Devienne <ddevienne@gmail.com> wrote:
>
> > On 6/15/07, Peter Reilly
> > <peter.kitt.reilly@gmail.com> 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 ;-)
Yes, I have been thinking of adding a spring linke bean type/task
(with ant-style attributes/element).
> >
> > > <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,

The build file level is completely BC as
the build file now contains the <addpropertyresolver> (or
similar) that informs ant on what to do
with property names starting with "bean:".

It also provides a "cool" BC compatible backdoor into allowing
modifiable properties.

>>  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"/>
Opps:
that should be <equals arg1="${bean:abc}" 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....
Awesome!

Peter

>
> 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:
> > dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail:
> > dev-help@ant.apache.org
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
> http://farechase.yahoo.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message