Jose,

Storing the reason for the withdraw in the metadata is sensible for the
moment.

I'm not so sure you would need to create the second view/DSpaceObject type
to attain rendering the output of a tombstone page.


           <xsl:when test="@LABEL='DSpace Item 2'">
               <xsl:call-template name="itemSummaryList-DIM-2"/>
           </xsl:when>

If a tombstone is put into place when the item is in a withdrawn state.
 AuthorizationManager and the XMLUI are going to try to block access to
render the item for users without READ permissions on the Item, forcing them
to view a password login or 403/401 error page that they do not have the
correct permissions to view the item.

I would extend at this point of the XMLUI so that there is another option to
only render the Tombstone when the XMLUI makes the decision to redirect to
an error page or a login page.  The conditions would then be

a.) Withdrawn? forward to tombstone page
b.) Restricted? forward to restricted page with choice to login

You can just write this tombstone page as a JAVA Transformer and get the
Item directly. This will allow you to avoid heavily altering the
DSpaceObject type in the mets generation and the controller logic.

By using this approach, you avoid going deep into making rendering decisions
and having to alter java code and most of the implementation should just be
in cocoon site maps and xslts.

See this decision making in the ArtifactBrowser…
http://scm.dspace.org/svn/repo/dspace/trunk/dspace-xmlui/dspace-xmlui-api/src/main/resources/aspects/ArtifactBrowser/sitemap.xmap


            <!-- restricted resource -->
                        <map:match pattern="restricted-resource">
                                <map:transform type="RestrictedItem"/>
                                <map:serialize type="xml"/>
                        </map:match>


            <!-- Handle specific features -->
                        <map:match pattern="handle/*/**">

                                <!-- Inform the user that the item
they are viewing is a restricted resource -->
                                <map:match
pattern="handle/*/*/restricted-resource">
                                        <map:transform type="RestrictedItem"/>
                                        <map:serialize type="xml"/>
                                </map:match>


*and further down the behavior that renders the restricted-resource view.*


<map:match type="HandleAuthorizedMatcher" pattern="!READ">
                                                <map:select
type="AuthenticatedSelector">
                                                        <map:when
test="eperson">

<map:transform type="RestrictedItem"/>
                                                                <map:serialize/>
                                                        </map:when>
                                                        <map:otherwise>

<map:act type="StartAuthentication">

 <map:parameter name="header"
value="xmlui.ArtifactBrowser.RestrictedItem.auth_header"/>

 <map:parameter name="message"
value="xmlui.ArtifactBrowser.RestrictedItem.auth_message"/>
                                                                </map:act>
                                                                <map:serialize/>
                                                        </map:otherwise>
                                                </map:select>
                                        </map:match>



Augmenting these with further conditional logic to handle that case where
the item is withdrawn would be to create another selector in java that
tested if the item was withdrawn and using it to render a transformer that
got that detail from the DSpace Item directly and rendered it as DRI
elements without actually retrieving the METS representation.  This would be
something that could be added into the site maps and codebase of the
ArtifactBrowser aspect without it impacting the theming tier much at all,
thus other institutions can immediately get the feature on the next upgrade
without altering their theming.

Best,
Mark


On Fri, Jul 22, 2011 at 7:05 AM, Blanco, Jose <[email protected]> wrote:

> Mark,
>
> I'm working on trying to get tombstone behavior to work in the xmlui
> environment.  I have it working on in the jspui webapp.
>
> So, I have successfully changed an aspect so that when an item is withdrawn
> a pick list of 3 options ( reasons ) for withdrawing the items is presented
> to the user.  I have also changed the code so that the "reason" is stored in
> a newly created dc element ( description.withdrawalreason ).  Now what I
> want is for when the user goes to the item, instead of getting an
> authentication request, he/she gets an item view page that looks just like
> the short display but shows the reason just above the where the bitstreams
> are listed and disable the ability to view the bitstream.  Here is an
> example from the jspui area:
>
>
> http://deepblue.lib.umich.edu/handle/2027.42/34788
>
> So I created a new aspect which is  a copy of ItemViewer.pm and have it
> called from the sitemap when there is no READ permission on an Item ( this
> will have to fine tuned to be more specific - like the item has a dc element
> with a withdrawalreason, but for now I can work with this ), so I'm trying
> to change my new ItemViewer file to create a DRI object that will render
> such a page.
>
> Does this help better understand where I'm at?  This change was fairly
> straight forward in the JSPUI world.
>
> -Jose
>
> -----Original Message-----
> From: Mark H. Wood [mailto:[email protected]]
> Sent: Friday, July 22, 2011 9:15 AM
> To: [email protected]
> Subject: Re: [Dspace-tech] from aspect to theme
>
> Part of the point of XMLUI's design is that Aspects and Themes aren't
> directly connected.  Aspects put stuff into the DRI for any Theme to use (or
> not) as it sees fit.
>
> A Theme is selected by the URI path to the page to be composed.  An Aspect
> can leave hints upon which a Theme can base decisions, but that's about all
> it can do in that direction.
>
> I agree that it would help if we heard more about the behavior you want the
> user to see, not in terms of DSpace components but rather of content,
> composition, and action.
>
> --
> Mark H. Wood, Lead System Programmer   [email protected]
> Asking whether markets are efficient is like asking whether people are
> smart.
>
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Web Security
> Learn 10 ways to better secure your business today. Topics covered include:
> Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
> security Microsoft Exchange, secure Instant Messaging, and much more.
> http://www.accelacomm.com/jaw/sfnl/114/51426210/
> _______________________________________________
> DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>



-- 
Mark R. Diggory
@mire - www.atmire.com
2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
Esperantolaan 4 - Heverlee 3001 - Belgium
------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks & Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to