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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
With Regards, Martin Taal
Springsite 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: [EMAIL PROTECTED] web: www.springsite.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
