Hi

I'm trying to grok the changes to the PropertyHelper in order to
document them for 1.8.0 - and maybe to suggest throwing in some more
built-in delegates, but that's for a different thread.

>From what I understand:

The default PropertyHelper splits its work into several steps that can
be delegated to custom implementations.  These steps are:

  * finding a property reference inside a string.

    The delegate interface is oata.property.PropertyExpander.

    There are two built-in expanders, one that finds ${foo} positions
    the parser after the '}' and says "here is property "foo"' and one
    that finds $$, positions the parser after the second $ (actually at
    the second $) and says "no property to be seen here".

    This is the interface I'd implement if I wanted a completely
    different property syntax.  I'd also need to implement it if I
    wanted to allow nested properties ${${foo}} since the default
    PropertyExpander doesn't balance braces.

  * mapping a property to a value

    The delegate interface is oata.PropertyHelper.PropertyEvaluator.

    There are two built-in implementations, one implements local
    properties and one implements the "toString: protocol",
    i.e. ${toString:some-refid} => find-reference-in-project.toString()

    This is the interface I'd implement if I

    - want to provide a different "protocol" like toString:

    - want to provide a different storage for properties, this would be
      the reading part of it.

    "Normal" project properties are not implemented via
    PropertyEvaluator but implemented via fallback mechanisms in the
    default PropertyHelper implementation.

    PropertyEvaluator can return Object but it will be turned into a
    String unless the whole string that was expanded is consumed by the
    property (i.e. "${foo}" can become an Object while "${foo} bar" van
    not).

    PropertyEvaluator can return an instance of the magical
    oata.property.NullReturn class which means "I really really mean it
    when I say the property expands to null" because simply returning
    null means "I don't know this property".

  * storing the value for a property somewhere

    The delegate interface is oata.PropertyHelper.PropertySetter.

    The only built-in implementation is for local properties.

    This is the interface I'd implement if I

    - want to provide a different storage for properties, this would be
      the writing part of it.

    "Normal" project properties are not implemented via
    PropertySetter but implemented via fallback mechanisms in the
    default PropertyHelper implementation.

    PropertySetter returns a flag indicating whether it has consumed the
    property - otherwise the other delegates are consulted and
    ultimately the fallback to project properties is used.

The <properthelper> task can be used to register custom delegates.
Delegates are used in LIFO order that is custom delegates are able to
override built-in delegates.

Is this correct and somewhat complete (Matt?)?

Stefan

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

Reply via email to