On 8 March 2010 19:15, Wendy J Bossons <[email protected]> wrote:
> May I join?
>
>
Absolutely.
> 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.
>
I've followed - at some distance - JSF ever since it was first announced. It
always had a certain amount of promise, but was to my mind held back by the
'JSP view' implementation (not that you are forced to use JSP).
> 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.
>
>From what I have seen, by far the best approach to using JSF is with Seam.
Seam has some really powerful features, that could allow some really useful
functionality to be created. And whilst part of me is keen to try it, I'm
concerned that it runs into the same issues that are causing some people to
look outside of XMLUI - that it is too heavy, both in learning and resource
usage.
But these are good and interesting areas to have discussions around.
Regards,
G
>
> ..\Wendy
> Wendy Bossons
> Web Developer
> MIT Libraries
> Technology Research & Development
> 77 Massachusetts Avenue
> Cambridge, MA 02139-4307
> 617-253-0770
> [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]> 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
