[4suite-dev] Repository Issues / Points

[Jeremy Kloth]

On Monday 31 October 2005 3:05 pm, Chimezie Ogbuji wrote:
> Some clarification.  SCore isn't *directly* interacting with the store
> driver (with regards to container management).  It's inheriting
> behavior *defined* in FtssDriver, so moving this behavior back *to*
> FtssDriver (for the sake of API sanity, convention,etc..) should be a
> light-weight refactoring effort:
>
> in Ft.Server.Server.SCore.ContainerImp:
>
> from Ft.Server.Server.Drivers.FtssDriver import DataStoreContainer
>
> class ContainerImp(XmlDocumentImp.XmlDocumentImp, DataStoreContainer):
>    .. snip ...
>

Another problem with the current design is that DataStoreContainer is being 
used as both a SCore object (by being a mixin to ContainerImp) AND a 
low-level driver (from inheritence of container implementation).  You have no 
idea how difficult THAT behavior was to decipher.  One method (and instance 
variables) for SCore and other methods (and instance variables) for the 
drivers.  Made my head hurt for awhile.

What I'm trying to do in my codebase is to flatten all that stuff into just 
single interfaces as there is no way (or desire) for a driver to NOT need to 
know about containers.  I am, however, thinking of introducing a base class 
(aka interface) for low-level drivers that achieves the same end result of 
DataStoreContainer's default behavior.  The bonus of this is to get a well 
documented starting point for all drivers (instead of simply copying an 
existing driver).

-- 
Jeremy Kloth
Fourthought, Inc.
http://fourthought.com/
http://4suite.org/