db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Taal <mt...@springsite.com>
Subject Re: cvs commit: db-ojb/src/java/org/apache/ojb/broker/accesslayer CollectionFactory.java
Date Fri, 15 Apr 2005 11:27:21 GMT
Okay thanks Tom, sorry, I was to quick (I thought so).

Here are some other thoughts about the collections in ojb. Hopefully 
they are of use to you (otherwise ignore them):

One thing which I noted is that for user-collection class it actually 
makes more sense to implement the TrackingCollection interface instead 
of the ManageableCollection interface. In the documentation of ojb 
however only the ManageableCollection is mentioned while it is not 
removal aware (which I think is very important).

Also the ManageableCollection interface only adds methods which are 
basically also offered by the Collection interface. Eventhough a 
user-defined collection should support the ManageableCollection the 
CollectionProxy class also assumes that the user-collectionclass is a 
valid java collection (when I look in the source code).
Maybe it would make more sense for user-defined collection classes to 
support the java.util.collection interface and if it should be removal 
aware also the TrackingCollection. The manageablecolleciton is then not 
required anymore (maybe only for backward compatibility).

gr. Martin

Thomas Dudziak wrote:
>>I looked at the CollectionFactory source you checked in and was
>>wondering if it was also possible to let the owner (the parent object)
>>of the collection be also passed to the createCollection methods in the
>>factory? The whole reason that I brought up the point of the
>>CollectionFactory is that I need the owner object during collection
>>construction. A collection factory is especially meaningfull in case
>>runtime information is required when creating the collection. However
>>the collection factory you checked in only allows the passing of more
>>static configuration information (i.e. collectiondescriptor). Or did I
>>miss something here?
>>You mention in the javadoc that collections should have a zero-argument
>>constructor because the collection proxies
>>create the collection on their own. However, if the collection classes
>>should required to be creatable by ojb code (and not by the factory)
>>then there is no real need for a CollectionFactory. If that restriction
>>applies then imo the CollectionFactory does not add more functionality
>>than the current CollectionClass attribute in the CollectionDescriptor.
>>Please correct me if I am wrong.
>>Sorry if my reaction is to quick, this specific feature is kind of
>>important for me that's why...
> As I wrote in the other thread, this is just the beginning :-) Right
> now the collection factory is simply the result of factoring out the
> determination and - in parts - the creation of collections for the
> retrieval of collection descriptors and for querying.
> However the creation of these collections is spread out across
> multiple classes, one of which is the collection proxy mechanism, and
> so it is a bit more difficult to unify.
> My plan in this regard is to first move the collection creation
> completely into the collection factory, and then add runtime info
> (e.g. the owning object) to the creation calls.
> This however will take some time which is why I left the isse in JIRA
> open (in progress) for now.
> Tom
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org


With Regards, Martin Taal

Barchman Wuytierslaan 72b
3818 LK Amersfoort
tel: +31 (0)33 462 02 07
fax: +31 (0)33 463 77 12
Mobile: +31 (0)6 288 48 943
email: mtaal@springsite.com
web: www.springsite.com

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

View raw message