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 Manakin was 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
