On 8/22/07, Matt Benson <[EMAIL PROTECTED]> wrote:
>
> --- Dominique Devienne <[EMAIL PROTECTED]> wrote:
>
> > On 8/22/07, Peter Reilly
> > <[EMAIL PROTECTED]> wrote:
> > Note that I'm lost in this discussion...
> >
> > > "${el:project.targets.get('not-present')}" should
> > resolve to
> > > "null" rather than
> > "${el:project.targets.get('not-present')}".
> > > - the string "null" cannot be used, it actually
> > needs to be
> > > an null object (when given to setAttribute(Object
> > val))
> >
> > But this is interesting and a bit worrying. Why
> > should it resolve to
> > "null" or a null object, rather than the empty
> > string "", or raise an
> > exception? In fact, returning
> > "${el:project.targets.get('not-present')}" is
> > consistent with current
> > Ant usage.
>
> I am starting to remember going down this road,
> myself, and deciding that it might be reasonable wrt
> least surprise to simply treat nulls as they always
> were. But that doesn't fully account for the
> situation where one really does want to allow null as
> a potential value one has pulled from some custom
> PropertyEvaluator to be set as a property of an
> Ant-managed type. We can continue down Peter's road,
> though I'd still like an opinion on the proxy
> mechanism I suggested for delegate recursion... :)
I did not reply because I did not understand the proposal :-)
> DD
Matt had added something to IH to allow Object to be returned
from property evaluation, I linked this to tasks/types that
say they understand Object by having a setX(Object) signature.
With local properties and setX(Object) in place one can do nice
things:
for example:
<target name="tasks" depends="init">
<el:for param="target" items="${el:project.targets.values()}">
<echo>TARGET "${el:target.name}"</echo>
<el:for param="task" items="${el:target.tasks}">
<echo> TASK ${el:task.namespace}:${el:task.tag}</echo>
</el:for>
</el:for>
</target>
which prints out:
tasks:
TARGET "clean"
TASK :delete
TARGET "for"
TASK :path
TASK antlib:org.apache.ant.el:for
TARGET "compile"
TASK :mkdir
TASK :compile
TASK :copy
TARGET "init"
TASK :typedef
TASK :propertyhelper
TARGET "tasks"
TASK antlib:org.apache.ant.el:for
TARGET "test"
TASK :typedef
TASK :echo
TASK :propertyhelper
TASK :property
TASK :echo
TASK :echo
TASK :echo
TASK :echo
TASK antlib:org.apache.ant.el:example
TARGET ""
TASK :path
TASK :presetdef
Of course going throu the build build is not a useful thing
to do, however, being about to access the attributes of
objects and iterating over them would be useful.
Peter
>
> -Matt
>
> >
> > Which setAttribute(Object val) are you referring to
> > Peter? A setter on
> > a task? Is it a good thing to have "untyped"
> > attributes like this?
> >
> > I'm just trying to understand the user-side behavior
> > of PH and the
> > Local Property proposal, but so far the picture is
> > muddy for me. --DD
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > [EMAIL PROTECTED]
> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> >
> >
>
>
>
>
> ____________________________________________________________________________________
> Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
> news, photos & more.
> http://mobile.yahoo.com/go?refer=1GNXIC
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
