ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Proposed API Refactoring
Date Tue, 05 Dec 2000 04:06:08 GMT
> From: Simeon H.K. Fitch [mailto:simeon@fitch.net]
> 
> 
> On Tue, Dec 05, 2000 at 12:24:20PM +1100, Peter Donald wrote:
> > At 09:58  4/12/00 -0600, Simeon H.K. Fitch wrote:
> > >Something I'm confused about, so be patient with me: If 
> the goal is to
> > >generate the Ant data model from some other info source than an XML
> > >file (say, a GUI constructed tree structure), why would 
> one want to go
> > >through the SAX interface to communicate with Ant?
> > 
> > well any number of reasons. If the data model is too 
> different from DOM
> > (Which I think it is) then it makes little sense to go 
> through DOM. But if
> > we have DOM sources then we must allow them to be used to 
> generate the
> > model. Remember DOM is just an input and not the final model.
> 
> What I'm looking for is a construction API that doesn't use SAX or
> DOM. If we want a general approach to generating Ant datamodels, why
> remain so w3c/XML centric?
> 

The beauti of standards is that you can interoperate with others.
I have no problen having an API, internally there is one. 
Externally, we can expose it, but if we deside to change the way
things work (like the proposal that was just checked in) it means all 
the external users have to go and rewrite their code.
Otherwise, we will need to support two structures the internal and the
external
a waist of time (in my opinion).

> <snip>
> 
> > Instead of having N project
> > builders it would be better to have N SAX producers and one 
> SAX Project
> > Builder. The reason for this is that there are already many 
> SAX converters
> > 
> 
> I don't see the benefit to having N SAX producers over N project
> builders. I would think that in the long term one would go through
> more contortions trying to generate the appropriate SAX events rather
> than directly building the project. Take the case where you want to
> store the project in a relational database, where you have separate
> tables for each data type (Target, Task, etc). Going to the w3c/XML
> SAX event API rather than instantiating the node types directly, or
> going through a factory seems a little weird.
> 

We do not have to create nor maintain the N SAX producers
SAX is a well known and supported API that we already support.
(That is the way we create the project from the XML file).
XML Parsers know how to produce SAX, DOM knows how to produce SAX,
XSLT translators know how to produce SAX, JDOM knows also, etc.

So, the only thing missing is to allow acess to it, there is nothing to
build.


> > out there and it means that the project builder can be 
> easily maintained
> > and there is less chance different input sources causing 
> projects to be
> > built inconsistently.
> 
> Couldn't various SAX producers be just as likely to produce
> inconsitent SAX events as any project builder? If we are trying to
> isolate ourselves from the construction of invalid project data
> structures, I have to argue that there are more straight forward ways
> that better support the Ant semantics (like a Factory approach that
> enforces the providing of certain data).
> 

SAX is a standard. Any compliant tool knows how to do it.
There are gazillion of tools that know how to do SAX, either directly
or thru one of these standard producers.

Bugs can be anywhere, we just need to take care that they are not ours.
For the rest, file a bug report and move on to a different implementation.

Jose Alberto
PD: How are you planning to implememnt <antcall> in your proposal.
The file does not exist anywhere and the task does not know about
any other way to get it.

Mime
View raw message