Tim: thank you for that walk-through of the Administrative aspect. It is very timely with some work that I'm doing. I'm curious, has anyone produced documentation, say perhaps a diagram (or several), of the various aspects and the flow of processing for them? I'm thinking something a bit more specific than Scott Phillips' excellent Manakin training slide stack (http://scott.phillips.name/wp-content/uploads/2009/05/tdl-manakin-training.pdf). The DSpace wiki has a great intro/overview of aspects for Manakin ( https://wiki.duraspace.org/display/DSPACE/Create+a+new+aspect+(Manakin) ) , and the JavaDocs for the XMLUI API (http://projects.dspace.org/dspace-xmlui/dspace-xmlui-api/apidocs/index.html) are helpful, too. But, if anyone has something more visual, to explain the flow of specific aspects, I'd love to see it. Thanks!
--Hardy > -----Original Message----- > From: Tim Donohue [mailto:[email protected]] > Sent: Thursday, October 07, 2010 10:00 AM > To: Walker, David > Cc: [email protected] > Subject: Re: [Dspace-tech] manikin question > > Hi Dave, > > Meant to get back to this discussion -- but, as you can see, it has > taken me a while to do so :) > > On 10/1/2010 4:22 PM, Walker, David wrote: > > If the goal here is to add an input button to the interface -- on the > 'confirm item' page, let's say -- I think it would be *significantly* > easier if the developer could just open an XSLT file, find the 'confirm > item' template, and just add the button like this: > > > > <input type="submit"> > > > > If someone wanted to then change that button to a link or an image, I > think it would, again, be significantly easier for them to locate the > 'confirm item' template, find that input element, and then change it to: > > > > <a href=""> > > > > Done. Easy. > > > > The way Manakin does it now, by comparison, seems both unnecessarily > complex and unnecessarily restrictive. > > > > To add a button to the interface, the developer has to write several > lines of Java code to create a pseudo-button DRI element and add it to > the XML response. > > > > And then if someone wants to change that element, they have to either > wade through a bunch of XSL templates to find the right one that can > override buttons, or edit the Java source code and then recompile and > redeploy Manakin. > > > > And that's just for this one very simple use case. If you need to > make (even slightly) more complex changes to the interface, like > actually *moving* elements around -- putting that button above or below > a different interface element, for example -- then you have to edit Java > code (cumbersome), or make large-scale changes to the XSLT (a lot of > work). > > > > That just seems ten times more difficult than opening-up an XSLT file, > and just editing actual HTML directly. Am I wrong? > > > > I think you have some good points you've made, and I appreciate it. > > However, it is worth pointing out a small flaw in this logic (at least > for HTML buttons or forms in general). Obviously, as we both know, a > button won't do anything unless there's some server-side code which > understands how to process that request. I agree with your point, that > there may be ways to make it much easier to add simple HTML elements > into Templates. However, there will still need to be some Java code > behind a button, which understands what that button needs to do when it > is pressed. > > So, maybe it's worth looking at a specific example here to make sure > everyone is on the same page. Let's look at how the "Administrative > Aspect" works in Manakin, specifically the single form that allows you > to Edit Metadata for an Item. Here's the general flow of how Manakin > creates that specific form (within the larger page): > > (skipping over some underlying logic in Cocoon sitemaps, just to > simplify) > > (0) Manakin sees you have the Administrative aspect enabled (it is > possible to *disable* an aspect, so if you did NOT have the > Administrative aspect installed/enabled, then you would be unable to > access this form and your DSpace install would essentially be > 'read-only'). Assume you are logged in as an Admin, so it will show you > this form. > > (1) The > 'org.dspace.app.xmlui.aspect.administrative.item.EditItemMetadataForm' > class generates the DRI version of this Form -- in DRI this form is > actually a <dri:div interactive="yes">. This <dri:div> also includes a > <dri:list> of all editable metadata fields, along with a few <dri:field > type="button"> elements which represent the buttons. > > (2) Assuming you are using the Reference Theme, it is loaded by Manakin > & called. > > (3) The Reference Theme calls the structural.xsl. In this file, the > template matching "dri:d...@interactive='yes']" is matched, and the XSLT > processing continues to match all the other templates in that file to > built the XHTML (for simplicities sake, I'll refrain from listing them > all -- plus as we've all already agreed this is a bit complex/confusing > at times). > > (4) The XHTML is built, CSS is applied & the page is shown to the user. > > (5) The user then edits some fields, and presses the "Update" button > > (6) This request is then processed by Manakin (Cocoon, actually). > Specifically, it's processed by the 'administrative.js' file under the > Administrative Aspect's config folder. This is a Flowscript file > (Cocoon's flowscript format is essentially javascript, but can embed > some Java calls). > > (7) In that flowscript file, the 'processEditItem()' method of the > 'org.dspace.app.xmlui.aspect.administrative.FlowItemUtils' class is > called. This method includes the Java code that actually *saves* the > metadata change, and updates the Item in DSpace. > > So -- the reason for this exercise is to show that there's unfortunately > a lot of complexities here, that we may be able to improve upon or clean > up over time. For example: > > A. I think Dave makes a good point that we may wish to try and push more > of the XHTML generation to the XSLs themselves (and simplify the amount > of content the Aspects themselves are generating -- to ease the ability > to customize pages). Whether or not this does away with DRI (or if it > just makes DRI much more simplistic, i.e. a smaller subset of itself) is > still not 100% clear in my mind. > > B. Obviously, as the above processing flow shows, some Aspects are quite > confusing and it makes it difficult to debug or add new content. It's > possible you'd have to look not only in XSLT, but also in multiple Java > files (the one generating the DRI and/or the one processing any form > requests), and potentially even the Flowscript. We can probably find > ways to simplify this, or at least make it more straightforward, so that > each developer doesn't need to re-determine the flow each time he/she > adds new content. > > > >> You can create your theme entirely from > >> scratch if you choose > > > > Totally. In fact, right now, I could rewrite the XSLT so that it > follows the page-based structure that I'm advocating for, and all > without having to touch a single line of Java code. > > > > Moreover, we could do that while basically ignoring 99% of the current > DRI XML response -- I know, because we actually started to do this > before realizing that having our own from-scratch theme would be a > maintenance nightmare. > > > > But that just further strengthens my belief that we don't need DRI, or > anything even like it. > > > > The XML will need to provide some information for the interface, no > doubt. But I see no reason at all to have the kind of quasi- > presentational XML elements that DRI provides. > > > > I'm not trying to dump on DRI. I'm really not. But, I think, until > the community can fully appreciate the problem that that approach > creates, there is a (totally understandable) reluctance to move away > from it. > > > > XSLT can handle *all* of the presentational logic, and makes both > building and customizing the interface so much easier. I know, because > I've seen it used that way in a number of other systems. > > > > I'm convinced that making the XSLT the (sole) presentation layer is a > much better approach. > > More interesting points. I'm still not 100% sure that DRI could be done > away with (you haven't swayed me completely yet). But, it could be that > a much more simplistic XML could be created (i.e. a smaller subset of > DRI) which could then allow XSLTs to create more of the page content > directly. > > In any case, this is very interesting discussion/brainstorming. I hope > we can continue it, and start to figure out possible routes forward. > > - Tim > > ------------------------------------------------------------------------ > ------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/dspace-tech ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
