Hardy, I cannot recall seeing any diagrams which describe the flow of specific aspects in Manakin. But, it's possible Scott or others on this list may know of some?
The best diagrams I know of are those from Scott's slide stack (which you already linked to). Those are a great overview of how Manakin (and Cocoon) work in general -- though they don't dig into the flow of very specific aspects. That all being said -- if anyone wants to generate such a diagram(s), I'm sure it'd be highly useful to many people in the community! :) - Tim On 10/7/2010 11:14 AM, Pottinger, Hardy J. wrote: > 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
