A simple example of checking for the existence of a file in XSLT +
java.io.File. This is Xalan centric, may break if you switch to using
Saxon, but there is as a similar way to do this with Saxon as well.
You could use this in your theme and check for the presence of your
derivative file, choosing to render your jp2 viewer or not.
<xsl:if xmlns:file="java.io.File" test="file:exists(file:new('/Path/To/File'))">
<!-- include your stuff here -->
</xsl:if>
Mark
On Thu, Apr 22, 2010 at 6:14 AM, John Preston <[email protected]> wrote:
>> 1.) Store the generated jp2 in a bitstream, create your own bundle, name
>> it whatever you want or store it next to the existing bitstream in the
>> content bundle if you want to also share the generated file for others to
>> use. Then expose the filesystem location of the file to your adore-jakota
>> viewer.
>> 2.) Store the generated jp2 file in an external directory that can be
>> calculated and rather than storing anything about this detail in the Item,
>> come up with a way to calculate the location of that file, if it exists,
>> then show your viewer.
>
> I intended to use 2 because I don't want to use the jp2 in a preservation
> context just to get zoomable viewing for large images. I intended to run a
> script periodically, or maybe triggered by an event, to generate the jp2
> files which should not interfere with the dspace files.
>>
>> (1) violates the storage layer boundary of DSpace, in the future you may
>> not have filesystem access to that file, but your getting the benefit of
>> storing the jp2 file in the assetstore as well. (2) is more respectful of
>> the storage boundary and but doesn't assure any preservation storage of your
>> generated file within DSpace.
>> I would choose 2 over 1 because it separates your implementation from
>> dspace internals, and in XMLUI can be implemented entirely in the theming
>> tier
>> You could take your own approach and generate a bundle/bitstream with some
>> sort of file system reference to the file. But there may be less chance of
>> breakage by repo managers if its a calculated reference rather than a stored
>> reference.
>
> The reference I use for calculating the jp2 file storage is <jp2 root>/<item
> handle>/<sequence id>/<file name>.jp2. The jp2 files will be available via a
> lighttpd web server to off load the file access from the dspace tomact
> instance. So I know how to construct the full path to the jp2 file. My issue
> is how do I simply save within the dspace context, the fact that I now have
> a jp2 derivative of this bitstream so that the item page can get a clickable
> link to enable the jp2 viewer. Bitstreams don't have there own metadata so I
> can't add anything that I could access in the xsl theme. I'm already using
> the description and I don't want to trouble that. I was then thinking of
> adding a dummy jp2 bundle, like what the filer media code does for
> thumbnails so that I could save the fact that a particular bitstream had a
> jp2 file available, but I'm not clear on how to do this for my needs. Any
> help here would be appreciated.
>>
>> I like (2) and if we had the development resources, I'd promote the idea
>> that we should have more than one possible "storage" tier for DSpace,
>> allowing maintainers to create there own separate storage locations for
>> derivatives that may require specific storage/access requirements and access
>> to by other applications. The work you do here could go to producing such an
>> API.
>
> That's fine by me but I would need some hints on which approach might give
> the best result.
>
> John
>>
>> Cheers,
>> Mark
>> On Wed, Apr 21, 2010 at 2:55 PM, John Preston <[email protected]>
>> wrote:
>>>
>>> Hi, I am seeking a little guidance here. I am setting up adore-djatoka
>>> with dspace 1.6. I have a dsrunable java class that goes through my
>>> collections and looks for all large image files and creates jpeg2000
>>> versions of these under a particular directory. After creating the jp2
>>> version of the file I want to create a dummy file in a new JP2000 bundle
>>> that I can manipulate within the xmlui to add a clickable link that will
>>> popup the adore-djatoka viewer to give access to the jp2 file.
>>>
>>> My question is how best should I store the jp2 file location, using a
>>> specific jp2 bundle say, to be able to manipulate it within the xmlui. Also
>>> how would the xsl code like like to access the name of the jp2 file location
>>>
>>> John
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> DSpace-tech mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>
>>
>>
>> --
>> Mark R. Diggory
>> Head of U.S. Operations - @mire
>>
>> http://www.atmire.com - Institutional Repository Solutions
>> http://www.togather.eu - Before getting together, get t...@ther
>
>
--
Mark R. Diggory
Head of U.S. Operations - @mire
http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther
------------------------------------------------------------------------------
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
