Thoughts inline:
--- Kevin Jackson <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> After throwing together a quick hack to support my
> substring
> properties use case, Matt suggested instead
> significant changes to the
> property helper class.
Sorry! :)
>
> After looking through the code this afternoon here
> are my thoughts on
> a possible way to implement a configurable
> propertyHelper
>
A Project uses the PropertyHelper registered under the
ant.PropertyHelper reference, so the pluggability is
already supported. Note additionally that the
existing PropertyHelper supports a PropertyHelper
delegate which, if set, will be given the opportunity
to resolve a given property. Note also that
PropertyHelper is a class, so any delegate
PropertyHelper will itself support a delegate. You
may now recognize the Chain of Responsibility pattern.
:) This feature was added by Costin Manolache, who
has since left us forever, so we'll get no help there.
:(
> 1 - Make the current PropertyHelper pluggable and
> allow users to
> specify which one to use at cli
[SNIP]
Personally I do see value in being able to have
multiple PropertyHelpers in action, but as the
alternative already exists between chaining and
outright replacement that's neither here nor there.
What is important here is that because the properties
"syntax" available in a given buildfile is completely
dependent on what PropertyHelper(s) is/are configured,
I think it's necessary that the mechanism for
registering a custom PH (by chaining or by
replacement) be available from within the buildfile,
and not so necessary that it be externally
configurable.
> 2 - Make a new task which is pluggable
>
> This would allow users the same benefits as a
> pluggable
> propertyhelper, but as it's a task, it can be
> configured entirely via
> xml
>
> This xml based config is perfect for my needs
To be honest, I'm not sure why we've not already
included a task to do the job. I first experimented
with replacing the PropertyHelper like:
<typedef name="myph"
classname="whatever.YouGetTheIdeaPropertyHelper" />
<myph id="ant.PropertyHelper" />
But I believe this ran into weird timing problems due
to how heavily the active PropertyHelper is used.
This has been a couple of years ago, so I don't
remember perfectly. :( If this (still) doesn't work,
a specialized task might; a task would/could obviously
also be less verbose and error-prone. A custom e.g.
"registerpropertyhelper" task could support chaining
and replacement by different options.
(I'm getting itchy to code this but am trying to
contain myself... :) )
Looking at the PropertyHelper code it might be useful
to add something like:
public void chain(PropertyHelper ph) {
if (next == null) {
next = ph;
} else {
next.chain(ph);
}
}
Probably synchronization should also be added to all
relevant methods here. Then <registerpropertyhelper>
could support different child elements: (root)? and
(chain)* . <root> would replace the ref'd
ant.PropertyHelper while each <chain> element would
add its object to the root (including the preexisting
root PH if <root> not specified) via the new chain()
method.
>
> 3 - Stick with my quick hack of a task and ignore
> the wider issues of
> how properties are handled
>
> This is basically throwing in the towel with respect
> to building a
> decent solution :)
And you can do that too. :|
>
> I'd love to hear feedback from anyone who has
> modified the
> PropertyHelper (I guess via a task as there doesn't
> seem to be any
> other way of getting custom behaviour implemented)
>
> What do you think with respect to how much effort is
> involved & what
> possible solutions exist? (I'm sure the 3 I listed
> are basically the
> tip of the iceberg)
>
The solution I outlined above MAY work-- :) --and if
so, doesn't _seem_ to be that terribly complicated.
Makes me wonder why we haven't already done it.
Finally, note that the class-level javadoc in PH
begins with "NOT FINAL. API MAY CHANGE" so if some
much more sensible solution arises that includes
drastic modification to the current PH API, that would
be an option (subject to a vote IMO) as well.
Hoping for input from others besides myself.
-Matt
> Kev
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
>
____________________________________________________________________________________
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
