May I join?
I agree that there is good support for CSS in XMLUI, and that is used here, as
well as modifications of the stylesheets.
I have been thinking about how the user interface could be made more flexible,
and to that end, I also propose that JSF may fit nicely. My background prior to
coming to MIT and DSpace was in the area of JSF and JavaEE on a separate
institutional repository software product. There is great headway in that
framework on the separation of concerns and also ease of use in the areas of
custom components, definition of the multi-step request-response lifecycle,
separation of concerns and templating support through Facelets and XHTML.
My understanding is that Spring and JSF work together nicely too, although I do
not have experience with the former -- other than having attended some
presentations at a JSFOne conference regarding its integration.
..\Wendy
Wendy Bossons
Web Developer
MIT Libraries
Technology Research & Development
77 Massachusetts Avenue
Cambridge, MA 02139-4307
617-253-0770
[email protected]<mailto:[email protected]>
On Mar 8, 2010, at 10:49 AM, Graham Triggs wrote:
Hi Christophe,
On 5 March 2010 15:50, Christophe Dupriez
<[email protected]<mailto:[email protected]>> wrote:
One book hopefully just stroked me on this topic:
"Transcending CSS: The Fine Art of Web Design" by Andy Clarke
http://transcendingcss.com/
The main idea demonstrated is the same than the intent of the XSLT layer:
Java code should provide a (user level) conceptual view of data that
XSLT should transform into presentation.
Just replace the word XSLT by CSS !!! Then:
* The user browser is working more to apply CSS on received XHTML data
* The DSpace server is working a lot less (no XSLT stylesheet to interpret)
* People with vision disabilities receives nicely semantically
structured data and are not bewildered with data structured for
presentation.
My opinion is that the benefit of XMLUI for much of the community is in the CSS
/ XHTML layer. I'll go further and say that there should be even less reason
for anyone to be changing anything other than CSS than there is now in either
user interface (this is along the lines of Rob's presentation at DSUG - we
mostly have common problems, and should have common solutions).
That's largely a separate argument to how you get to an XHTML data model
though, even though I do favour a simpler and less resource intensive route to
achieve that.
The corollary of this is that project development then follows these steps:
1) Interaction design: what is the succession of steps a user may be
requested to do for a given task?
2) Generation design: what is the data tagged with "user level" concepts
(using XHTML and microformats) that must be sent to the user browser?
Does the DSpace Java generation layer for XML-UI could be used as
a basis of such semantically tagged xHTML
(removing XSLT processing from the server) ?
3) Presentation design: how this data is presented on the Web page: CSS
only is enough!
CSS can even change the **ordering** of data blocks on the page.
Well made points - the 'Java generation layer' is a bigger and separate
discussion (for these purposes).
* all programming is in one language: Java (JSP eases the upper level of
generation)
Simplicity, performance, scalability...
This is where I would urge you to take a look at the work I started in the
'webmvc' module:
http://scm.dspace.org/svn/repo/modules/webmvc/
It's not as far developed as I would like it to be before discussing it, but as
we are touching on this area, we might as well.
Much of the project revolves around using Spring WebMVC to provide the split
between code and template/view that is not completely captured in the existing
JSPUI.
But also, it's using Freemarker to provide that means of translating a Java
object model into XHTML. The benefit of using Freemarker is that you can't have
code embedded into templates the same way that you can in JSP (some conditional
statements are provided), and you have more freedom in loading templates from
anywhere (making it possible to provide a way to edit/replace/override those
templates without redeploying the application). What's more, Freemarker (unlike
Velocity) allows you to use JSP tag libraries - so if you are coming from a JSP
environment, you can still make use of tag libraries if necessary, without
replacing them.
I see it as a really good trade-off between ease of use, familiarity, and
flexibility. Yes, there are some things that you can do in XMLUI with the
aspect / pipeline approach that would be easier to migrate between version
upgrades (it may be more likely that you have to merge changes to a template on
a Freemarker project than if using XMLUI), but you have to balance that against
the immediacy and resource requirements of the simpler approach.
G
<ATT00001.c><ATT00002.c>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
