Hi Giedrius, I'm impressed by the amount of work you're putting in here... thanks!
On 20 September 2012 21:13, Giedrius Graževičius <[email protected]> wrote: > Hi, > > > The second is to do what I originally had in mind, which is to leave > these > > values in regular value ObjectAdapters (where getOid() returns null); and > > then to have some sort of Facet on the corresponding ObjectSpecification > to > > act as a hint to the viewer not to render the value. > > Currently building an adapter requires to access the value, thus it > will be loaded. My idea is to create a type of adapter that doesn't > need the value, but takes an accessor and parent as arguments. It > would only call the accessor when Adapter.getObject() is called. Thus > we can avoid calling it in the viewer (ex. until user clicks > 'Download' link). > gotcha. And now I'm reading this back and having looked through your slide deck, I agree. There's more on this below. > > > Can you expand on what you're doing here? > > > Slides uploaded: > http://inightmare.org/ishare/ISIS-254-1.pdf > > OK, so have looked through your slide deck (though not any of your code). The following are more thoughts/observations. In general, all positive stuff. ~~~ 1. Per another thread, think we should combine: - LazyPropertyFacet - a hint for lazy loading of properties - CommonlyUsedFacet - a hint for eager loading of collections My suggestion was to merge these into a new @ResolveHint annotation: ResolveHint(LAZY) / ResolveHint(EAGER). You might have seen that Kevin also thought this a good idea, so I'll do this today in order that you can build on this. ~~~ 2. Why is ContentDescription and the describeXxx() method required? Wouldn't an annotation do? eg: private byte[] attachment; @Blob(mimeType="text/plain") public byte[] getAttachment() { ... } public void setAttachment(byte[] attachment) { ... } The name of the attachment could be inferred from the property name (with the suffix derived from the mimeType, perhaps). My idea is that @Blob annotation would imply ResolveHint(LAZY) (ie would install two facets on the OneToOneAssociation). ~ 3. per the "pending problem" you've listed (as to knowing whether or not a blob property is populated), one option might be to do something similar to the @PersistedTitle annotation that I've proposed in a different thread; in other words to have Isis automatically maintain a separate "flag" property. eg: private byte[] attachment; @Blob(name="default.txt", mimeType="text/plain") // implies @ResolveHint(LAZY) public byte[] getAttachment() { ... } @PersistedBlob("attachment") // implies hidden public boolean getAttachmentPopulated() { ... } public void setAttachmentPopulated() { ... } The viewer could then search for the flag property and, if available, then use it. ~~~ 4. per the ObjectAdapterMemento issue, I agree with the intent of your proposed solution. The issue that needs to be addressed is that, normally, the ObjectAdapter obtained from OneToOneAssociation.get() for a value type (eg byte[]) has a null Oid. In order to create a lazily evaluated ObjectAdapter, it'll need to have some sort of way of re-obtaining the value, ie have a non-null Oid. In a different thread I suggested having these blob values be considered as an aggregated adapter, ie an ObjectAdapter where Oid is non null and of type AggregatedOid; in essence the value is now treated similarly to a reference. If you went down that route, then the serialization of the parent ObjectAdapter into an ObjectAdapterMemento would just store the AggregatedOid. So, have a play around with that. I think you'll need to get into the guts of AdapterManager#adapterFor(...); you'll probably need a new overload public ObjectAdapter adapterFor(final Object pojo, final ObjectAdapter parentAdapter, OneToOneAssociation otoa). This could be really easy, in OneToOenAssocation.get(), we currently do: @Override public ObjectAdapter get(final ObjectAdapter ownerAdapter) { ... return getAdapterManager().adapterFor(referencedPojo, ownerAdapter); } so instead, this might become @Override public ObjectAdapter get(final ObjectAdapter ownerAdapter) { ... return getAdapterManager().adapterFor(referencedPojo, ownerAdapter, this); } ... giving a rather pleasing symmetry with the equivalent code in OneToManyAssociation. ~~~~ Cheers Dan > > Giedrius. >
