incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <dkhayw...@gmail.com>
Subject Re: Adding support for documents and pictures as a value type.. ?
Date Thu, 07 Apr 2011 07:00:49 GMT
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>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message