I really appreciate you taking the time to discuss this, Tim. You make a lot of good points.
> For example, a submit button is encoded as > <dri:field type='button' n='submit'> . How and where that is > displayed/presented to the user is up to the XSLT -- it can choose to > make that an <input type="submit">, an <input type="button">, a > <button>, an <a href="">, any other XHTML element, or even choose > to hide it altogether and not display it. I guess I just have a hard time understanding how this is advantageous. 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? > 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. --Dave ================== David Walker Library Web Services Manager California State University http://xerxes.calstate.edu ________________________________________ From: Tim Donohue [tdono...@duraspace.org] Sent: Friday, October 01, 2010 10:17 AM To: Walker, David Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] manikin question Hi Dave & all, First off sorry for the semi-long email. On 9/30/2010 4:56 PM, Walker, David wrote: > So, wrapping up this long-winded criticism -- you did say this was okay > right, Tim? ;-) -- I don't think it would actually take much to improve > Manakin. Yes. Perfectly OK. I actually got a laugh out of your side comment here :) > First, just do away with the DRI schema. > > Have the aspects Java code simply create XML that is semantically (rather > than presentationally) marked-up. Just give us the data for communities, > collections, items, and the submission process. Just the data as XML. I actually feel that DRI mostly *IS* semantic markup (though not to the same degree as say RDF). There are places where I agree it does fall flat and move too much into presentation/layout markup (e.g. tables and similar). If you read through the "Intro to DRI" (http://www.dspace.org/1_6_2Documentation/ch15.html#N189EE) you'll see it is actually mostly based on TEI (http://www.tei-c.org/index.xml), which itself is again mostly semantic in nature. Here's a decent overview of TEI and the history of it: http://www.ibm.com/developerworks/library/x-matters30.html DRI elements were *never* meant to be directly equivalent to XHTML elements (and maybe the fact that some are named the same is what can be so confusing). So, <dri:div> is not the same as XHTML <div>. <dri:div> is just a means of grouping particular content into separate "sections", and could be represented by any number of XHTML elements (<div>, <table>, <td>, <p>, <form>, etc.) To take this slightly further: if you take a look at many of the DRI elements, they really are NOT necessarily layout/presentation specific. They just define a generic page element. For example, a submit button is encoded as <dri:field type='button' n='submit'> . How and where that is displayed/presented to the user is up to the XSLT -- it can choose to make that an <input type="submit">, an <input type="button">, a <button> , an <a href="">, any other XHTML element, or even choose to hide it altogether and not display it. DRI is merely suggesting that this page may need some sort of way to submit a set of fields. Ok -- I'm bordering on a <rant> here, and not meaning to. :) I just wanted to point out that DRI was not initially meant to force the page into a particular layout. It's more of a way to encode the contents that should be displayed on the page (and linking together page contents coming from a variety of sources, e.g. plain text on a page tends to come from messages.xml, item metadata from a METS file, sometimes other content is generated via other DSpace configs, etc.). However, that being said, over the years some of the Manakin Java Aspects have used DRI better than others. I think there are areas we need to *fix* Java Aspects that are too limiting and force the page into a particular structure, etc. There also may be areas that we may also want to fix DRI, if we find it really is encoding too much of the page's content (some of which can and should be left to XSLT themes). If it came to it, I'm not against replacing DRI with something better -- but we need to be careful that we aren't just pushing the problem elsewhere or creating a new problem. :) Obviously, this would also be a huge project which would need plenty of community volunteers, if we ever wanted to take it on. > Second, push all of the presentational logic into the XSLT files. > > Create templates that correspond to "pages" in the system. If the interface > needs a<div> or a paragraph or a submit button, that should all go into the > XSLT. That is where it belongs, in the presentational layer. > You'll then have a clean separation of concerns, easy to figure out > templates, and happier developers. I think the problem here is what has been mentioned several times. Simply put, that /dri2xhtml/structural.xsl is just way too confusing and way too big. :) I agree with this completely. To be clear (and many of you may already know this), you don't *have* to use dri2xhtml when creating a new Theme. You can create your theme entirely from scratch if you choose (though obviously that is much more work). From my understanding, dri2xhtml was initially made by the creators of Manakin as a very simplified way to transform DRI into very basic XHTML for display (I mean "simplified" in terms of it's not very flashy or dynamic, nor is it meant to be the "one and only way"). From what I've understood, one of the other original expectations for Manakinwas that folks in the community would start to build new and better templates, and eventually that default "Reference" theme (which is essentially just dri2xhtml with very minimal CSS) would go the way of the dinosaurs. I'm fully and completely in support of someone creating a better default template that better maps templates to "pages" (or perhaps sections within pages, in some cases). I think that is entirely possible to do right now (with no or minimal DRI or even Java Aspect changes). For instance, if you look at the DRI output for the DSpace Homepage (e.g. our demo site: http://demo.dspace.org/xmlui?XML ), you'll see several explicit sections to that default page which could be pulled out into separate templates: The main News: <div id="file.news.div.news"> The Front page Search area: <div id="aspect.artifactbrowser.FrontPageSearch.div.front-page-search"> The list of Communities: <div id="aspect.artifactbrowser.CommunityBrowser.div.comunity-browser"> Each of those could be mapped to a separate template immediately, as they all have unique IDs which could be used to match a template. > Easy for me to say, right? ;-) Yep! All of this is easier said than done. :) I really do appreciate the feedback/discussion. You see I come from a slightly different point of view, but I can understand there are limitations to the current DRI. It definitely is worth closer investigation on whether there is (a) a more flexible way to use the current DRI in aspects to avoid too much separation of concerns, OR (b) an improved version of DRI we can create, OR (c) a replacement for DRI altogether Just my personal thoughts. I don't have a magic sword that I can wave around and make any of this happen immediately. It all takes volunteers and discussion to bring it forward. But, it's great to point out some of the flaws & limitations so that we can work to make it better over time. - Tim ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech
