Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 43207 invoked from network); 29 Jul 2002 08:15:13 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Jul 2002 08:15:13 -0000 Received: (qmail 24554 invoked by uid 97); 29 Jul 2002 08:15:41 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 24533 invoked by uid 97); 29 Jul 2002 08:15:40 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 24516 invoked by uid 98); 29 Jul 2002 08:15:39 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <36E996B162DAD111B6AF0000F879AD1A76BF56@nts_par1.paranor.ch> From: "Wannheden, Knut" To: 'Ant Developers List' Subject: RE: Embed Sandbox Proposal: HOWTO? Date: Mon, 29 Jul 2002 10:15:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C236D8.0DF2F0FA" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ------_=_NextPart_001_01C236D8.0DF2F0FA Content-Type: text/plain; charset="iso-8859-1" > From: > > > 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 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 ------_=_NextPart_001_01C236D8.0DF2F0FA--