ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: [PATCH] myrmidon task configurer
Date Sun, 30 Dec 2001 23:10:31 GMT
On Mon, 31 Dec 2001 01:19, Adam Murdoch wrote:
> > It should be possible for a task or any object to only have it's
> > subelements
> > Configurable and where that is not the case there will be a base utility
> > class (see AbstractTaskContainer) to help do the configuring.
> > This utility
> > class will allow the task to call back into the configurer to do the
> > configuring. AbstractTaskContainer is not real easy atm but it
> > sort of shows
> > what I was aiming at.
> >
> > WOuld this be enough for you ?
>
> Not quite.  You certainly *could* do this with Configurable - the issue is
> that it's an all or nothing approach.  If an object (task or data type)
> implements Configurable, then it has to take care of configuring itself,
> and all its nested objects.  It also needs to take care of resolving
> properties and doing type conversions (and presumably the new stuff like
> reference handling and polymorphism). 

At the moment it may - however in the future when I finally get around to 
reworkin AbstractTaskContainer there will hopefully be much simpler 
mechanisms in place that will hide a lot of this complexity. 

Im not sure how to make this easier and still keep the system relatively 
simple. 

> Granted, using AbstractTaskContainer
> makes it easier to do this if the object in question happens to be a task. 
> Not much good for a nested type, however.

True but how often do you need a nested type to behave in such a way? Off the 
top of my head I can't think of any examples of nested types that aren't 
tasks. So lets say we had something like

<if test="foo">
  <blah/>
  <blee/>
</if>

Then both <blah/> and <blee/> would be tasks and configured by the container.

The IfTask would simple configure itself and then pass <blah/> and <blee/> 
back into the container to be ran as tasks.

Can you give a sample task where the nested type is not a task?

> E.g:
>
> public class SomeDataType extends AbstractDataType
> {
>   /** @deprecated Needed for backwards compatibility - use {@link
> #setSomeAttr(File)} instead. */ public void setSomeAttr(String value) { ...
> }
>
>   public void setSomeAttr(File value) { ... }
>
>   /** Returns the configurer to use for this class. */
>   public static ObjectConfigurer getConfigurer()
>   {
>       DefaultObjectConfigurer configurer = new
> DefaultConfigurer(SomeDataType.class);
>
>       // Force the introspector to use the File setter method for
> "some-attr" configurer.enableAttribute("some-attr", File.class);
>
>       return configurer;
>   }
> }

Okay - in Ant2 the "contract" occurs at the XML representation/task model 
level. So in this case there would be no need to have a deprecated version 
because we could simply delete the old string-based version.

> > > * Deal with references.
> > >
> > > Have the configurer resolve (and type check) references to data types,
> > > rather than forcing the object do it.  An adder method would be
> >
> > passed an
> >
> > > object, and whether that object was obtained by reference, or
> >
> > created and
> >
> > > configured inline, the parent object doesn't know or care.
> >
> > +10000
> >
> > The two ways I proposed for doing this were basically recognizing
> > some magic
> > constructs.
> >
> > One construct would be that any element/attribute name that ended
> > with "-ref"
> > would have the "-ref" part removed and the normal attribute/element
> > configuration process would proceed except that it would use the
> > reference.
> >
> > The other constrct is just recognizing the case where an element has one
> > attribute named refid and treat it specially.
> >
> > I favour the first method as it deals with attributes and elements and is
> > generally easier IMHO but the second method is more standard to
> > our current
> > approach.
> >
> > What do you think?
>
> Not entirely clear on how elements are handled in the first method.  Want
> to expand on it a bit?

Consider the following. All three <javac/> tasks would be identical. 

<path id="foo">
  <pathelement value="..."/>
</path>

<javac classpath-ref="foo"/>

<javac>
  <classpath-ref id="foo"/>
</javac>

<javac>
  <classpath/>
    <pathelement value="..."/>
  </classpath>
</javac>

Like that?

> Logging would be the main one - say I want to do logging in some deeply
> nested obect, I need to have something pass me a Logger.  Ideally, my
> object would simply implement LogEnabled, and the container would supply
> the object with a Logger as part of its "initialisation".  The alternative
> would be for the object's parent to supply the logger - this would be bad,
> as it would force the parent to be LogEnabled.
...
> It's possible that a data type might need other components, or the task
> context, to do its work.  Again, having the container supply these would be
> a good thing.

I would like to move away from having sub-elements being "intelligent" and 
move towards them just being passive data containers. When you need to get 
generate complex information from these items (like processing a patternset 
to get a list of files) you pass these passive data items to a active service 
(ie FileScanner or something) that would do all the magic for you.

-- 
Cheers,

Pete

*---------------------------------------------------------*
| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |
*---------------------------------------------------------*

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


Mime
View raw message