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 DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
