incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: ManageableCollectionUtil should not throw "unsupported" JcrMapping exception.
Date Sun, 03 Sep 2006 22:36:28 GMT
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
> >
> >
> >
>
>

Mime
View raw message