incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer" <ke...@kmz.co.za>
Subject Re: Adding support for documents and pictures as a value type.. ?
Date Thu, 07 Apr 2011 14:00:05 GMT

Within

>> 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() { ... }

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.

> There would be a corresponding MimeValueFacet in the metamodel for this
> to be picked up; an unannotated MimeValue could default to "text/plain",
> say.

text/plain could be the default, if no other type could be determined by
inspection of the byte stream / Name, or specified by the user.

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

>> What about "browse..."&  "upload" buttons to sent content?
>>
> That'll be harder ;-)  Certainly do-able with the Wicket viewer, eg see
> [1]

hmmm.. that prompts a another question - to follow in a separate message...


Mime
View raw message