Re: Java Project API/SPI

On Tue, 2003-07-22 at 11:11, Svatopluk Dedic wrote:
> Jan Pokorsky wrote:
> > Java Project API refinements:
> > 
> > In order to make the api classes less overcrowded with methods and to 
> > prevent future compatibility issues I would propose to split following 
> > classes to API and SPI part:
> > 
> > 1. ProjectPath:
> > http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/ProjectPath.html
> > 
> >   API: the class should be final. Just static methods would remain.
> >   SPI: introduce
> > public abstract class AbstractProjectPath {
> >   public abstract PathResource handleCreateResource(FileObject filebase)
> >        throws IOException;
> >   public abstract ClassPath getPath(ProjectMember object, Object type);
> > }
> 
> What is the "handleCreateResource" method for ? It is not obvious from 
> the javadoc at all; shouldn't be the fact, that PathResources are based 
> on FileObjects (indirectly through ProjectMembers) or included in some 
> fixed sets of Classpaths an implementation detail of each provider ?
> 
Sorry for that, I will add the documentation later this week,
the handleCreateResource is a abstract method, which must be
implemented by concrete ProjectPath.
The method is called by the client static method createResource, this is
a factory method for creating simple dir/jar/zip resources.

Tomas
> > 
> > 2. JavaProject:
> > http://www.netbeans.org/download/prj40_prototype/javadoc/JavaProjectAPI/org/netbeans/api/java/project/JavaProject.html
> > 
> > 
> >   API: the class should be final. Remove needless support methods like 
> > fireXXX, listenerAttached.
> >   SPI: introduce public abstract class BasicJavaProject containing all 
> > support methods and those neccessary for proper functionality of the 
> > api.JavaProject.
> > 
> What is the advantage of this design over implementing directly the API 
> method by the provider ? Is the number of abstract methods (the methods, 
> which in fact define the project's functionality) small enough so that 
> richer final API class can be built around a small set of SPI methods ?
> 
> -Svata
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>