Hi All

For those interested here is a link to our theme files.
See: http://staff.lib.sun.ac.za/~hgibson/files/SCHOLAR.tar.gz
These are from the webapp modules folder.
All are welcome to use it.

We did a mod to remove the login and search on the front page.
See: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Asset_Presentation#Structural_changes

And the result is: http://scholar.sun.ac.za

Perhaps a space somewhere officially can be created to address design and styling ?

Cheers

hg

On 01/10/2010 19:17, Tim Donohue wrote:
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

-- 
Hilton Gibson
Systems Administrator
JS Gericke Library
Room 1053
Stellenbosch University
Private Bag X5036
Stellenbosch
7599 
South Africa

Tel: +27 21 808 4100 | Cell: +27 84 646 4758

"Simplicity is the ultimate sophistication"
	Leonardo da Vinci