Adding support for documents and pictures as a value type.. ?

[Kevin Meyer - KMZ <ke...@kmz.co.za>]

I see that there is an oai.applib.value.Image value type and value 
semantics provider, to support byte[][] arrays (generic images, I 
guess).

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)?

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".

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 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?).


Is this straight forward? really tricky?

What about "browse..." & "upload" buttons to sent content?

Re: Adding support for documents and pictures as a value type.. ?

[Dan Haywood <dk...@gmail.com>]

Kevin and I have been having an off-list conversation.  Thought it 
worthwhile cc'ing onto the list.

~~~
Kevin,

within

On 07/04/2011 14:57, Kevin Meyer wrote:
>
>> @MimeType("application/pdf")
>> public MimeValue getDocument() { ... }
> Mrr.. I suspect MimeValue would need to be generic enough that the
> "MimeType" would be a property that can be determined by looking at
> (for example) the byte stream (a la *nix's Magic Number engine) or
> by media name... I'm assuming that Name would correspond to the filename.
>
Not sure about that idea.

My idea was motivated from thinking about how HTTP responses work, where 
the mime-type is specified as a content header before the body of the 
response (ie the stream).  If it works well enough for HTTP, it ought to 
do for us.

Just did a little digging into the JDK... looks like 
javax.activation.DataSource sort of represents what I meant.  One of the 
out-of-the-box implementations is URLDataSource, or we could provide a 
ByteArrayDataSource etc.

Worth raising a ticket for?


>>> 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).
> Actually, I'm saying that the thumbnail *is* a representation of the
> content, not the fact that is a (e.g. PDF, vs spreadsheet). Like the
> thumbnail that you see in Nautilus... For images, this is dead easy,
> for other document formats, a little more tricky..?
>
> But this would require (for example) that if iconName() returns a string
> beginning with ^ (or whatever), look in an alternate directory for the
> icon.... ? Otherwise it must "just" return a full, absolute (server
> relative) path.
>
Yes, understood.  Rather than invent lots of new conventions, I think a 
good first pass would simply be to allow the iconName() to return a URL, 
that the viewer could fetch and render appropriately.

Worth raising a (different) ticket for?

Re: Adding support for documents and pictures as a value type.. ?

[Dan Haywood <dk...@gmail.com>]

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>