Hey Mark, Good to hear your perspective on this. I wanted to respond to some of your broader comments here, and then circle back to some specifics ones in a separate email.
> In @mire, we are highly invested in the DRI solution at this > time, proposing a major change in DRI for DSpace 1.7 is > not something that @mire will support Indeed, I can't imagine that the community would support a change of this scale for the 1.7 release. However, I do hope that the community would consider rethinking Manakin's design long-term. I fully appreciate, too, that this change would come at a significant cost, both in terms of development resources and disruption to the current install base. But part of my goal here is to point out that the current Manakin design represents a significant cost to the community, too. Look no further than this very thread, where Jose is struggling to implement what should be a fairly simple change. And yet Manakin's current design makes this task much harder than it needs to be. It is costing him (and us, and others who are struggling with the complexity of Manakin) a lot in terms of time and resources. It doesn't need to be this hard. > So, to be clear, the ability to construct nested divisions, > lists, options, meta sections is quite powerful for getting > the structure of the content pushed into the presentation layer. I appreciate your opinion here, Mark. And, yet, I think this illustrates precisely why DRI is problematic. How the content is structured on the page *is* presentation. Conceptually, you cannot "push" that to the "presentation layer." Any code (regardless of where it lives) that defines the structure of the page *is* the presentation layer (or at least part of it). So, in Manakin, some presentational logic is set out using DRI in Java Aspects code. And other presentation logic is set out (or overrided) in the XSLT. Having presentational logic in two different places is mixing concerns, which leads to confusion. And -- at least in my experience -- Mankin is unique in doing it this way. Pretty much every other system we use here -- and almost any other system you care to name -- uses some kind of web templating system for its interface. Most don't use XSLT, but, regardless of which templating system they do use, the interface is constructed in the *templates*, not back in the programming source code. Templating systems (including XSLT) are good at this task -- much easier than programming code -- which is why they were invented. I'm simply proposing that Manakin should use the XSLT in this way too. --Dave ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu ________________________________________ From: mdigg...@gmail.com [mdigg...@gmail.com] On Behalf Of Mark Diggory [mdigg...@atmire.com] Sent: Thursday, October 07, 2010 6:00 PM To: Walker, David Cc: Mark H. Wood; dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question David et al. I have been following this discussion and trying to determine an appropriate point of entry. So lets dive in... In @mire, we are highly invested in the DRI solution at this time, proposing a major change in DRI for DSpace 1.7 is not something that @mire will support due to the impact it will have on our clients dspacesolutions. Likewise, discussion internally has lead to an opinion that breaking up the xslt into separate files for each page actually defeats the design goals of the XMLUI theming tier. I.E. having one file within which all customizations reside to manage your theme. Using separate files that are overridden introduces a variant to the current approach and possibly more confusion about which template is being applied. The current mechanism relies solely on xslttemplate priorities for the determination of what templates will be overridden in one theme and we prefer this approach. --- This said, however, I have always been interested in alternatives to METS for flagging the content necessary for rendering a view... The separation of DRI and METS was a bit of an evolutionary attempt to improve the performance and there are some kludges within it. the original design, embedded METS within the DRI, and this it served a "container-ship" role in aggregating all the data that was necessary for the view. Performance required the separation of METS under another pipeline for rendering that content. There are further kludges that introduce a "pseudo XPath" capability to retrieve only specific portions of the METS document"... which is further complexity that end users are unaware of. It was this division of content that made the role DRI less clear. To be honest, the use of generating whole METS docs and handing them to the theme to enable the theme developer to add/remove content from the views is what broke the separation of concerns. It is the "References and ReferencesSets" that point at METS documents that violate the generation of content only in the aspect tier. This became very clear when working on Discovery, I became aware of the use of METS as a source for the search, browse and recently added resultsetsin a search is a bit of over engineering and an attempt to model the older JSPUI approaches to selecting the fields from the actual Item object that should be present in search results... Its actually quite a pain to get around. This choice of approach actually makes it more difficult to use the output from the Solr search engine (return fields, hit highlighting, ranking info, etc) to assist in rendering. In which case, I was actually more interested in rendering the search engine results as DRI list elements and not as a set of METS references. I still feel this way, and in which case, for the long term, I'm promoting a solution for discovery that is still DRI centric. So, changing the use of DRI in this area will derail that development direction. So, to be clear, the ability to construct nested divisions, lists, options, meta sections is quite powerful for getting the structure of the content pushed into the presentation layer. We are talking here about not just the semantic structure of the page to be rendered but also the content of the DSpace item, community, collection etc. I see an argument here about "form fields" vs. "links". And this is an example of why we want to use Aspects to generate the content of the page (including the required inputs) as opposed to having the theme developer do it. Adding a form field is a Aspect developer project, deciding if its a plain old textbox or some dynamic html rich text widget is a theming/branding activity. In fact, if one were to make any changes to DRI, it might be argued, based on the above examples, that Most of DRI interactive forms would have been better suited to be Cocoon CFORMS (http://cocoon.apache.org/2.2/blocks/forms/1.0/489_1_1.html). This would have made it very clear that Aspects produce page structural content (including forms) and that Themes simply style that content and give an opportunity to override some the output. This would have reused a key set of tooling already developed in the Cocoon community and in use today in projects such as Apache Lenya. CFORMS are the converse of javascript flow that Tim was talking about, rather than using CFORMS, TAMU instead invented a custom mechanism for representing interactive sections of content in DRI. CFORMS could be employed to replace Interactive DRI sections or at the theming layer to brand the existing DRI as CFORMS. Both are probably viable approaches. Mark On Thu, Oct 7, 2010 at 11:23 AM, Walker, David <dwal...@calstate.edu> wrote: >> We still need some way to build a bag of structured, >> labeled data and action handles, so that when a >> Theme reaches into the bag it can know what to grab > > Yes, right. And this is really easy to do: > > <label>data</label> > > It'll probably need to be more complex than that, of course -- but not much. > >> If we do away with DRI we will have to invent >> something almost like it. > > But what I just described above is nothing like DRI. Unless you count the > fact that they are both XML. > > DRI tries to accomplish a whole bunch of things that a simple attribute-value > pair does not. But, IMO, those things are unnecessary. > > All we *need* is a simple mechanism to get data to the interface. Anything > beyond that just complicates and confuses the process. > > --Dave > > ================== > David Walker > Library Web Services Manager > California State University > http://xerxes.calstate.edu > ________________________________________ > From: Mark H. Wood [mw...@iupui.edu] > Sent: Thursday, October 07, 2010 10:40 AM > To: dspace-tech@lists.sourceforge.net > Subject: Re: [Dspace-tech] manikin question > > Well, one thing which occurs to me is that <dri:field type='button'/> > should instead be something like <dri:action/> and let the Theme > figure out whether it wants to lay out a button (or anything else) > which links to the action. These "button" fields are really just > abstract handles for things the user can ask to have done. If they > weren't *called* buttons, they wouldn't look like presentation. > > If we do away with DRI we will have to invent something almost like > it. We still need some way to build a bag of structured, labeled data > and action handles, so that when a Theme reaches into the bag it can > know what to grab and make good use of XSL facilities to do so. > > What's going on here, it seems to me, is that the current design > strives for separation of concerns between data and presentation > across the Aspect/Theme boundary but perhaps has not quite achieved > it, compounded with the use of terms in DRI which we are conditioned > to think of as presentational. > > -- > Mark H. Wood, Lead System Programmer mw...@iupui.edu > Balance your desire for bells and whistles with the reality that only a > little more than 2 percent of world population has broadband. > -- Ledford and Tyler, _Google Analytics 2.0_ > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > DSpace-tech mailing list > DSpace-tech@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dspace-tech > -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
