incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: ManageableCollectionUtil should not throw "unsupported" JcrMapping exception.
Date Mon, 04 Sep 2006 08:45:10 GMT
Dan,

I'm sorry but I don't understand what you are doing.
If you need to support another kind of collection (or Map), there are
2 alternatives :
1/ Build your own ManageableCollection and reference this class in the
mapping file.
2/ or promote this class into the ManageableCollectionUtil (if this is
a generic/well know collection or map).

Please, let me know why it is not possible to create a simple
ManageableCollection ?
In therory, you should know modify the code managing the collections
inside the framework.

Thanks,
Christophe


On 9/4/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> On 9/4/06, Dan Connelly <dsconnelly@adelphia.net> wrote:
> > What I ended up doing for this problem, to avoid the exception, was to
> > make a local modification in ManageableCollectionUtil.    It still
> > throws the exception (if needed) but my specialized list collection
> > class is now easily coerced to a ManageableCollection with my
> > replacement code.
> >
> > This is a hack, but a much smaller hack than trying to specialize either
> > the objectConverter or the collectionConverter to do the wrapping.
> >
> > I would like to see the CollectionConverter interface extended with a
> > method:
> >  private  ManageableCollectionFactory  getManageableCollectionFactory()
> >  such that the ManageableCollectionFactory class would be used in much
> > the same way that ManageableCollectionUtil is ued.
> >
> > The ManageableCollectionFactory would continue to throw the
> > "unsupported" JcrMapping exception (if needed), but presumably would
> > wrap all of the application's collection classes correctly.
> >
> >
>
> I haven't liked the fact that the framework is using this factory like
> class to handle collections, but haven't got the time and energy nor
> the time to refactor it. A good refactoring patch would be pretty
> welcome.
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> >
> > Dan Connelly wrote:
> >
> > > I want to use a custom collectionConverter, MyCollectionConverterImpl.
> > >
> > > That collectionConverter can decide what to do with "unsupported"
> > > collections from my *given* object model.   (Object model cannot be
> > > changed.)    In particular, MyCollectionConverterImpl will wrap  an
> > > unsupported collection as a ManageableCollection and delegate its work
> > > to a standard collection converter.
> > > The collection type is discovered by reflection in the
> > > objectConverter, so it cannot be coerced in the ocm mapping.
> > >
> > > Unfortunately, the default objectConverter invokes its own wrapping
> > > tool, ManageableCollectionUtil, just before the call to
> > > insertCollection in the custom collectionConverter.
> > > ManageableCollectionUtil will throw an exception before the custom
> > > collectionConverter gets its chance to wrap the unsupported collection
> > > type.     The call to insertCollection in the custom
> > > collectionConverter is never invoked.
> > >
> > > A workaround would be to over-ride method insertCollectionFields using
> > > a custom objectConverter.   However, this method  is private in the
> > > standard objectConverter.  Thus the method work cannot be delegated.
> > > Code would need to be copied into the custom objectConverter.   Not
> > > good.   But even if this method was public and code copying was not
> > > needed, the object converter is not the right place for collection
> > > conversions.
> > >
> > > Why not make the collectionConverters responsible for throwing an
> > > exception on (truly) unsupported collection types?
> > > Don't throw this exception from ManageableCollectionUtil.   Just leave
> > > an "unsupported" collection type alone there and let the
> > > collectionConverter deal with any unsupported collection type that may
> > > be given to it.
> > >
> > >       -- Dan
> > >
> > >
> > >
> >
> >
>


-- 
Best regards,

Christophe

Mime
View raw message