Conal, This is a good example of a simple aspect, thank you for sharing with everyone. I wanted to address a few points in Dorothea's email
On Feb 5, 2008, at 9:53 AM, Dorothea Salo wrote: >> I agree on the separation of concerns, adding content to the page >> should be a different task than changing its "look and feel". > > I don't necessarily *disagree* with this, but let me ask: is it > possible to shoot some communities/collections/items through a > specific Aspect and others not? > > Because if not, there's an assumption hidden in the Manakin > architecture that I don't think is going to hold water: that all parts > of a DSpace repository are going to want the same behaviors over (or > even information about) their contents. > Aspects are interactive components of the repository - they are code that bridge the gap between a user interface and the dspace-api. So, yes in the manakin architecture aspects apply to the whole repository while theme apply to individual communities/collections/items. We made this decision on purpose - where aspects are active in that they are code which can processes values. Themes are passive they just happen and typically do not make functional decisions. If you have an aspect that you only want to 'turn on' for specific communities or collections then that's fine, just have a configuration parameter specifying what contains they aspect should effect. Then in your aspect have it look at the parameter to decide how it should modify the DRI document. > I'm not a visual designer (I'm actually completely awful at it; I can > implement other people's visual designs, but the ones I create myself > are garbage). I'm more of an interaction designer, which tends to > suspend me rather uncomfortably over the "adding content" versus "look > and feel" divide. To me, "look and feel" is not a frill, and it's not > intrinsically separable from the behavior of the application. > You're right it's not a clear line what is adding content vs look-and- feel. In fact in Conal's example it could really go either way and depends upon the context. He stated that they are really effecting the underlying datamodel of the repository's bread crumb trail - i.e. it's irrespective of the style in which the page is being viewed. In this case an aspect makes the most sense. However a change to the bread crumb trail in another context may make the most sense at the theme layer. For example, if you were modifying the bread crumb trail to adopt the style of an external website in such a manner to allow seamless integration between they external website and the repository then the appropriate place is within a theme. This is a stylistic choice that is only applicable to one specific theme and not really changing the repository, it's just transforming it to be in-style with the pre-existing external website. That's probably not the answer you wanted to hear :( > By way of example... I could write an Aspect that put enough > information in the DRI to turn DSpace into a halfway-decent > image-collection display application, with nice thumbnail-based > navigation and all. (Well, I probably couldn't, actually, but I see > how it's possible.) If I turn that Aspect loose on my entire > repository, however, I am choking DRIs with a lot of unnecessary > information in collections that don't contain images. > > Ditto for writing an Aspect designed to navigate through page views > for an item containing a mess of ordered TIFF images. (I don't think > that's possible in a Theme!) > > I suspect this mindset of mine has led to communications problems on > my part in the past, and is liable to lead to more... but in all > honesty, I'm worried that Manakin may have too narrow a sense of "look > and feel" to be optimally useful for diverse DSpace repositories. > > Dorothea > > -- > Dorothea Salo [EMAIL PROTECTED] > Digital Repository Librarian AIM: mindsatuw > University of Wisconsin > Rm 218, Memorial Library > (608) 262-5493 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
