apols for not coming back sooner on this...

On 18 September 2012 20:02, Giedrius Graževičius <[email protected]> wrote:

> Hi,
>
> I've summarized what has been done on ISIS-254 (slides attached).
>

... hmmm, confused.  No slides attached to this email ... they get stripped
off.   And no slides attached to ISIS-254 either.

So, can't comment.




>
> > Anyway, to my question:  What is the most appropriate method of
> > telling the SQL-OS to not automatically load these values?
>
> I suspect SQL-OS managed entities are not encapsulated in some
> adapter/proxy, similar to how other ORMs (like DataNucleus) is does
> this. As then you can track all invocations and also replace
> collections to your own tracking collection types.


Ah, I posted something similar in my reply to Kevin just now.



> [snip]
>
> We also need viewers not to access the property, but I guess it should
> work by using reference adapters (as Dan suggested).
>

That wasn't quite what I meant, I had intended to say for these blob values
to be handled just like any other value, at least so far as the viewers
were concerned.

But now I see that that was wrong.  It'll be important to ensure that the
viewers don't eagerly try to render these blob values.

There are two possible solutions.

The first, as you are suggesting, Geidrius, is to wrap blobs in a reference
adapter (which are not generally eagerly loaded by the viewers). One
possible option is to synthesise an aggregated ObjectAdapter (ie where its
getOid() returns an AggregatedOid).

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.

In fact, some sort of Facet will be needed in either solution, in order
that the viewer renders the correct sort of "widget".

Of these two solutions, I marginally prefer the second.  But the first
isn't that much different... though the code it would use is newer,
and thus less  tested.




> Ref to were the magic happens:
>
> http://apps.inightmare.org/source/xref/apache-isis/framework/runtimes/dflt/runtime/src/main/java/org/apache/isis/runtimes/dflt/runtime/memento/Memento.java#129


Confused.  Not quite sure what I'm meant to be looking for here... Memento
is about capturing snapshots of state in between interactions, eg as used
in the Wicket viewer's serialization of state, and as previously used for
remoting.

Can you expand on what you're doing here?

Thx
Dan



>
>
> Giedrius.
>

Reply via email to