Hi Giedrius, I have some time right now to look into file support for the SQL-OS and the htmlviewer, if you want any help.
I don't know if you read my previous thread on this topic[1]. Regards, Kevin [1] http://isis.markmail.org/message/bfgrdyq727m5s3jk On 13 Sep 2012 at 8:09, Dan Haywood wrote: > 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 Grazevicius <[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
