Hi Giedrius, (First, I'm cc'ing this onto the mailing list, because I think it's relevant to the wider community.)
Anyway, +1 for continuing on the file/blob support. With respect to the lazy loading stuff you are talking about (and apologies in advance if you've already figured the following), there is already some infrastructure in Isis to do lazy loading: namely the org.apache.isis.runtimes.dflt.runtime.system.persistence.ObjectFactory interface, with a cglib and a javassist impl. (NB: when configured, they must be paired with corresponding impls of org.apache.isis.core.metamodel.specloader.classsubstitutor.ClassSubstitutor). The object factory was designed to take care of lazy-loading of references, but actually it would also work, I think, for values. So from the viewer-side of the AdapterManager, I believe we have things covered. The work that does need doing for blob support, I think, is to find a way to stop the back-end objectstores eagerly setting blob values into the entity when it is rehydrated. As you mention, JDO does this automatically, so my guess is that there's no work to be done for that object store. But the other object stores would need some work doing on them. All that said, it's quite possible you've traced this through more thoroughly than I and know something I don't ... In which case, put me right! Cheers Dan On 12 September 2012 19:55, Giedrius Graževičius <[email protected]> wrote: > Hi Dan, > > [snip] > > The idea now is to leave property lazy loading for the future and > instead concentrate on the following: > - finish Wicket support for 'files' > - explore which object stores don't support binary fields (MongoDB is > a suspect here, as it will need a bit different approach, SQL should > be pretty trivial). > - create some kind of facet describing the binary data in case it is > actually some content/file. The idea is to have describeFieldName > function which would return a descriptor that gives a hint on content > type, file name, etc. This would also allow different viewers to react > to this description, in case it's a file it will pass the filename and > mime type to the browser. Or viewer might decide to display some mime > types differently. If it's 'image/png', maybe it should be just > displayed instead of downloaded. (Some mechanism of providing viewers > for those mime/types might be a nice idea). > - align other viewers with Wicket functionality (Scimpi, HTML; maybe > figure out some way to make a request for it in RestfulObject viewer). > --> until this point we have binary field support, but the field will > always be loaded with entity (even with JDO, which actually loads > BLOBs lazily), because when building an adapter Isis will get the > actual value from the property. > - finally find a way to build lazy adapters for some of the > properties, such adapter a) would not require the actual value of the > property to be constructed; b) it would only load the value when the > actual call to adapter.getObject() is called. As an experiment I had > an idea to skip AdapterManager for lazy properties and just build a > special kind of adapter that takes a parent and a getter Method of the > property (I moved a big part of PojoAdapter to AbstractAdapter and > implemented the logic I described here, however bypassing > AdapterManager and putting custom logic in the viewer didn't seem > right, so there is a need to think about how adapters should be > constructed in a way, that the construction logic wouldn't leak to > view viewer layer). > - add support for lazy loading to SQL and MongoDB backends (here some > JDO style proxy or some other (Facet based with some specific lazy > loading provided by each store?) mechanism could be employed). > > [snip] > > > Thank you for your interest, > Giedrius > >
