Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
From: Alex Karasulu <aok123@bellsouth.net>
Organization: Solarsis Group
To: "Maven Developers List" <dev@maven.apache.org>
Subject: Re: ModelFactory interface (was: maven-model-tools to ...)
Date: Mon, 12 Jan 2004 1:51:49 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-Id: 
 <20040112065149.DTRV1950.imf18aec.mail.bellsouth.net@mail.bellsouth.net>

Forgot to mention another reason why it might be a good idea 
to convert the Model and its depenent classes to interfaces
and use default objects.  Store optimization requirements 
may necessitate the tracking of whether or not instances of 
these objects are dirty.  Underlying implementations may
want to add these extra bits of information to enable the
process and still extend other classes et. cetera.

> 
> From: Alex Karasulu <aok123@bellsouth.net>
> Date: 2004/01/12 Mon AM 01:28:14 EST
> To: <dev@maven.apache.org>
> Subject: ModelFactory interface (was: maven-model-tools to ...)
> 
> Hi,
> 
> Sorry my shxty mail client and jittery cafinated fingers prematurely
> sent my last email incomplete so I'm resending it again.
> 
> As I recommended I would use the factory method pattern here where
> the creator is the factory.  The ModelFactory interface is the 
> interface for all factory implementations.  I would go with something
> like so which is based on CRUD:
> 
> /**
>  * Creates a new Model within a backing store using supplied parameters.
>  *
>  * @param a_model the Model to create within the backing store
>  * @param a_params the parameters needed to access the backing store
>  * @throws ModelStoreException if there is a failure accessing the backing
>  *     store or the Model already exists within the backing store
>  */
> void create( Model a_model, Properties a_params ) 
>     throws ModelStoreException ;
> 
> /**
>  * Reads a Model from a backing store using supplied parameters.  Note
>  * that the primary key uniquely identifying a Model is a composite key
>  * based on the artifactId and the groupId.
>  *
>  * @param a_artifactId the id of the artifact associated with the model
>  *     as a part of the composite primary key
>  * @param a_groupId the id of the group associated with the model as a
>  *     part of the composite primary key
>  * @throws ModelStoreException if there is a failure accessing the backing
>  *     store or the Model specified by the artifact and group ids does not
>  *     exist within the backing store
>  */
> Model read( String a_artifactId, String a_groupId, Properties a_params )
>     throws ModelStoreException ;
> 
> /**
>  * Updates a Model within the backing store using supplied parameters.
>  *
>  * @todo consider the behavoir to default to a create op if the Model 
>  *     does not exist within the backing store
>  *
>  * @param a_model the Model to update within the backing store
>  * @param a_params the parameters needed to access the backing store
>  * @throws ModelStoreException if there is a failure accessing the backing
>  *     store or the Model does not exist within the backing store
>  */
> void update( Model a_model, Properties a_params ) 
>     throws ModelStoreException ;
> 
> /**
>  * Deletes a Model from the backing store using supplied parameters.
>  *
>  * @todo consider the behavoir to default to a no op if the Model 
>  *     does not exist within the backing store instead of throwing 
>  *     an exception
>  *
>  * @param a_model the Model to delete from the backing store
>  * @param a_params the parameters needed to access the backing store
>  * @throws ModelStoreException if there is a failure accessing the backing
>  *     store or the Model does not exist within the backing store
>  */
> void delete( String a_artifactId, String a_groupId, Properties a_params )
>     throws ModelStoreException ;
> 
> Ok so let me make some statements on the bs I just carved out here.
> First I just made up an exception type to use here which would wrap
> the gambit of exception types that may result from the underlying
> factory implementations. Second you never know what parameters are 
> going to be needed by an underlying implementation so I use a set of
> Properties here like the way JNDI does to accomodate the needs of the
> underlying provider.  Now why use Properties instead of Map or a
> Hashtable as does JNDI?  #1 there is a set of Properties that are 
> already loaded from the project.properties files and #2 if users 
> were to add model specific parameters it would be there - there 
> would be no project.xml to read after all.
> 
> So model factory implementation and it's connection parameters can 
> be stored within the project.properties file and accessed by the
> factory via the Properties argument.
> 
> As I mentioned before the ModelFactory interface is the abstract
> creator and the implementations are concrete creators.  The product
> is the Model.  Note that it might be best to factor out interfaces
> for Model and its subordinate object classes in the containment 
> model.  I would use the current implementation classes as DefaultXYZ
> classes.  This allows factory implementors to implement their own model
> value objects and still be able to extend other superclasses.  Most 
> implementations will however most likely use these default model 
> value object implementations anyway.
> 
> Oh and another thing if you store some type of property for the
> fully qualified model factory implementation class name within
> the project.properties file the proper factory implementation can
> be instantiated that way.  If the property is not specified the
> default implementation (XML based factory) can be used instead.
> 
> Can't think of another better way right now to manage factory 
> creation than the above but I'll reply back to myself if a better 
> means comes to mind.
> 
> Alex
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org