On Fri, Jul 22, 2011 at 10:28 AM, Blanco, Jose <blan...@umich.edu> wrote: > > Mark, I was kind of trying to do this. I started by creating an > ItemViewerNew ( transformer ) using the esiting ItemViewer that was already > there but modifying as necessary to have the reason for withdraw show up on > the short display. According to what you are saying I should be able to > create this new ItemViewerNew transformer without ( hopefully ) impacting the > theme, but I’m not seeing it. Don’t I need a new theme to put the reason > code just above where the bitstreams are listed, and how do I eliminate the > capability to click on the link that lets you go to the bitstream.
Not if you use the ArtifactBrowser aspect to generate the message, basically, your writing the DRI elements in Java rather than looking up the METS doc in XML/XSLT calls. You would be doing something like: Item item = (Item) HandleManager.getObject(handle) DCValue[] values = item.getMetadata(….). and then creating a DRI div to hold the message you retrieved. ------ What I am proposing eliminates your working in the theming layer and creating a separate view for rendering the Tombstone that is not subject to the complexities your finding in the ItemViewer. For this you would be doing the following: a.) Creating a Transformer and adding DRI sections in its body method b.) Looking up the DSpace Item via the provided handle. c.) Rendering the message by getting the metadata out of the item for the view that is of interest in this case. This would be the simplest approach to rendering a view and would be useful in the next release. You would add: 1.) TombstoneView.java as a transformer 2.) Add a section before the "restricted" sections in ArtifactBrowser site maps. 3.) Write a "WithdrawnSelector" that will allow the site map to have conditional logic to determine if the item is withdrawn or not. 4.) Wrap the following section with that selector so that you can execute the WithdrawnView on the handle prior to the restricted view being evaluated. <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> > > > > From: Mark Diggory [mailto:mdigg...@atmire.com] > Sent: Friday, July 22, 2011 11:32 AM > To: Blanco, Jose > Cc: dspace-tech@lists.sourceforge.net; Mark H. Wood > > Subject: Re: [Dspace-tech] from aspect to theme > > > > 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 <blan...@umich.edu> 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:mw...@iupui.edu] > Sent: Friday, July 22, 2011 9:15 AM > To: dspace-tech@lists.sourceforge.net > > 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 mw...@iupui.edu > 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 > DSpace-tech@lists.sourceforge.net > 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 -- 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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
