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