ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <knut.wannhe...@paranor.ch>
Subject RE: Embed Sandbox Proposal: HOWTO?
Date Mon, 29 Jul 2002 08:15:09 GMT
> From: <costinm@covalent.net>
> 
> > On Fri, 26 Jul 2002, Wannheden, Knut wrote:
> > 
> > > But otherwise sounds good!  This will make a cleaner 
> interface for people
> > > writing custom frontends as they can supply their own 
> ProjectHelper and
> > > practically call it with any input.  Just the 
> ProjectHelper knows how to
> > > deal with it ;-)
> > 
> > I think you are talking about frontents supplying their 
> ProjectHelper 
> > implementations, not replace oat.ant.ProjectHelper. 
> > 
> > That's how it think it should work.
> 

Yes, I guess I didn't distinguish the two quite clear enough.  But IMHO the
two should be renamed somehow, because their responsibilities are still
quite different.  The oat.ant.ProjectHelper unfortunately has both the
responsibilities to act as the interface for a ProjectHelper implementation
(as ProjectHelperImpl) and as a factory like object which delegates to the
appropriate ProjectHelper implementation.

So a frontend could then encompass a ProjectHelper implementation, some main
entry point (as oat.ant.Main) and maybe some own BuildListener and
InputHandler.

> I agree in part. I think APIs passing "Object" should be 
> avoided as much as posible.
> They say nothing about the constraints imposed by the API. It 
> makes no sense to
> pass things other than those able to produce an stream of 
> input to the current implementations
> of ProjectHelperImpl.
> 

Why a stream of input?  As an example is a DOM tree certainly not a stream,
not has it necessarily been constructed from one, but it is perfectly suited
as input for an Ant project.  In this case I think Object as input makes
perfectly sense as it should really be left up to the implementor what kind
of source he'd like to read the input from.  But of course he has to know
that he will have to deal with File objects if he uses the <ant> task or the
like.  In this case he might just delegate to the standard
ProjectHelperImpl.

But I agree the default ProjectHelperImpl provided by Ant should probably be
able to handle URIs not only Files, but I guess this is the general idea
anyways.

> A more useful functionality would be to able to pass 
> something like a URL from
> which these parsers can obtain their imput.
> 
> For other types of ProjectHelperImpl implementations, they 
> should be able to use a
> URL or URI type syntax to describe the input to their 
> implementations. This would
> at least maintain a strongly typed API.
> 
> With respect to having an API to spacify the PHI to use, I 
> think that is defenitly good
> as one may have the autoload settings to use PHI2 and at the 
> same time have other tools
> requiring their own PHI.
> 
> Jose Alberto

--
knut

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message