On Thu, Nov 15, 2012 at 11:28 PM, Jason Sherman <[email protected]> wrote: > Thanks for the information, it was very helpful. I started out > attempting a solution similar to what you suggested, but I just > couldn't easily get it to work properly. I managed to get something > working using the xlink:title attribute. I've attached my mets:file > template and a representative mets.xml file so you can see how it > works. I'm going to add another choose/when/test in there so no > lightbox code shows up unless there is definitely a preview bitstream, > but it works for my immediate needs.
Ouch, this hurts my eyes. What's with the variablttln names? I'd also shorten at least "$context/mets:fileSec/mets:fileGrp" into another variable to make it more readable. So is there anything you'd like to improve in this part? > As for the larger issue of branded previews not being linked to the > original bitstreams, I've had less success. This doesn't appear to be > something that handled by the media filter itself, rather it seems to > be handled by the xmlui api. For instance the ItemAdapter class > [https://svn.duraspace.org/dspace/dspace/trunk/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java] > marks THUMBNAIL and TEXT bundles as derivatives of ORIGINAL bitstreams > upon. However, this is hard coded. I tried adding in > 'BRANDED_PREVIEW' to this and another class with hard-coded bundles, I'm not quite following. What are you trying to achieve? 1) Didn't your numbering rules and my matching code work? 2) I thought you made it work using the title attribute instead, so what do you want to do here? I'd avoid modifying Java classes unless you really need to because you'll have to remember to forward-port your changes on each upgrade. The more such changes you make, the more reluctant you'll be to upgrade, trust me. > and then doing a clean build and update of DSpace, but it doesn't seem > to have any effect. Did you run "mvn package" (or "mvn clean package") in [dspace-source] or in [dspace-source]/dspace? The latter would rebuild only changes in overlays and somesuch and wouldn't care about your changes in dspace-xmlui. See quick build vs. full build here: https://wiki.duraspace.org/display/DSPACE/Rebuild+DSpace No need to run "mvn clean package", but it may save you from some nasty surprises, so I'd run it only if something doesn't work as expected after "mvn package" (it's just quicker). > I also tried building new jars and dropped them > into my install, but it didn't work either. I'm not really familiar > with java development though, so I may be making a silly mistake. I don't think the jars you built contained your changes (see above), but there would be another gotcha - if you went around ant and did the copying manually, you would need to copy them in 2 places - both [dspace]/lib and [dspace]/webapps/xmlui/WEB-INF/lib/ Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
