Within,
On 06/04/2011 19:51, Kevin Meyer - KMZ wrote:
I see that there is an oai.applib.value.Image value type and value
semantics provider, to support byte[][] arrays (generic images, I
guess).
That's the idea, though I admit that I haven't tried to integrate in
Wicket, and I don't think that the HTML viewer does either.
There's a chance that the DnD viewer supports it, and perhaps also Scimpi.
Unless Rob knows better, my view is that it's only a partial
implementation; as you've noted, we don't capture the mime type.
But what would be required to support embedded documents with, I
suppose, MIME types that could be used to call out to system handlers
to load and display (e.g. a PDF document will be opened by Acrobat or
evince, or whatever)?
It's an interesting question. The short answer is that we don't yet
support this. I see there being two parts to this problem:
a) the metamodel needs to capture the required information
b) the viewers need to know what to do with it.
As a way to address (a), I wonder if it might be better to deprecate
oai.applib.value.Image (which assumes a rectangular array of bytes, ie
byte[][]) and replace it with a more general purpose
oai.applib.value.MimeValue (or something similar), and then introduce a
new @MimeType annotation for properties of this value, eg:
@MimeType("application/pdf")
public MimeValue getDocument() { ... }
There would be a corresponding MimeValueFacet in the metamodel for this
to be picked up; an unannotated MimeValue could default to "text/plain",
say.
Addressing (b) would then be a matter of updating the viewers one-by-one.
I am particularly thinking about the browser client-side resources to
handle this in the HTML / Wicket / Scimpi viewers... where there
should be mechanisms to "open/download", "update/upload".
This is certainly doable; Naked Objects MVC (on .NET) does support
something like this already. So technologically, there's nothing to
prevent it from being done.
For images, I have a mental picture of an icon (thumbnail view) being
immediately visible on the viewer - as a clickable link. Clicking on the
link would fetch the actual document. Does this break the Isis viewer
paradigm?
I don't have a problem with that.
I guess the iconName() method could be used to return the
thumbnail... then the "value" would be actual content, and handled by
the browser already (provided the correct content type was sent to the
browser?).
Yes, it can be used as well; but I think it should only be considered as
a hint to the content of an object (in the same way that an object's
title is a hint also). And... there can only be one icon, whereas you
might want to have multiple mime values for an object (eg
front/side/back elevations of a Building, say).
Is this straight forward? really tricky?
The metamodel stuff should be pretty easy.
What about "browse..."& "upload" buttons to sent content?
That'll be harder ;-) Certainly do-able with the Wicket viewer, eg see [1]
Cheers
Dan
[1] http://www.wicket-library.com/wicket-examples/upload/single
<http://www.wicket-library.com/wicket-examples/upload/single?1>
