On Mon, Nov 19, 2012 at 10:01:23AM +0100, helix84 wrote: > On Fri, Nov 16, 2012 at 6:03 PM, Jason Sherman <[email protected]> wrote: > > 2) I was hoping to make a more general-purpose solution for derivative > > bitstreams. If I create a new media filter, I'd like to be able to > > mark it as a derivative and group it with the original. That way my > > templates could access any derived bitstream in the same way as > > thumbnails. It would make adding filters and adding their bitstreams > > to the ui much more intuitive. Maybe this is a development issue? > > Good thinking. If you manage to make something like that, it would > surely make similiar development easier. It won't get into DSpace 3.0 > at this time, but you have plenty of time for 4.0. Just file a Jira > issue when you have something ready or ask here if you need more help.
+1 > >> 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. > > > > Sage advice, I'll take it. I've been tracking which files I've been > > messing with. I think I'll revert them and move my experiments to > > another server. It may make more sense to try to contribute to dspace > > instead of managing local patches. That's a cart before the horse, > > though. > > Yes, you figured out the ultimate reson for contributing. After the > local developments pile up, they become quite unmanagable. :-) [snip] > > Good point. On line 695 of the item adapter class > > [https://github.com/DSpace/DSpace/blob/dspace-1_8_x/dspace-xmlui/dspace-xmlui-api/src/main/java/org/dspace/app/xmlui/objectmanager/ItemAdapter.java#L695] > > I made the following change > > - if ("TEXT".equals(bundle.getName()) || > > "THUMBNAIL".equals(bundle.getName())) > > + if ("TEXT".equals(bundle.getName()) || > > "THUMBNAIL".equals(bundle.getName()) || > > "BRANDED_PREVIEW".equals(bundle.getName())) > > > > I thought that would cause isDerivedBundle to be set to true for > > branded preview bitstreams and thus get assigned the original > > bitstream's group id. It doesn't seem to alter the behavior though. > > I thought that I had a problem with my build process, but I made your > > suggested directory change and I still get the same result. Branded > > previews are still getting unique group ids. Ideally there would be a > > place to register additional bundles as derived, but again, this may > > be creeping into a discussion more appropriate for development. > > I can't think right now of anything that can go wrong there and don't > have the time to fiddle. Sorry! That ever-lengthening list of hardwired tests seems to point to deeper problems. I'd like to suggest that the ultimate problem is that the whole idea of Bundle is wrong. Containment is the wrong model. Just about the only Bundle that will ever contain more than one Bitstream is ORIGINAL. Things like TEXT and THUMBNAIL are really class-membership flags, and ORIGINAL can be seen that way too. I think a more general solution would involve abolishing Bundle and describing the Bitstream more directly. It could use simple flags: when extracting flat text, for example, give it the DERIVED flag and the TEXT flag. Or it could be done with valued attributes: this Bitstream has DERIVATIVE("TEXT"). Or it could be a complex set of RDF objects with relationships going off in *all* directions. This probably needs some debate. -- Mark H. Wood, Lead System Programmer [email protected] Asking whether markets are efficient is like asking whether people are smart.
pgp4EUDg80XjP.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
