Hello, Just my $0.02. We are pretty devoted to supporting the XMUI interface for all our clients. Likewise, the work done last year on DSpace 2.0 was primarily XMLUI centric for the demo and showed us that there is a great deal of flexibility that can be gotten out of Cocoon.
At this time we are working with @mire and NESCent to implement the Solr based "Discovery" UI for DSpace 1.6.x that is entirely based on XMLUI, I do not anticipate writing anything similar for JSPUI or any other user interface project. the XMLUI is sufficient for rendering SolrJ, XML and JSON Output and we anticipate using it as well to create a Proxy for more generic Solr querying that is Access Controlled on top of Solr, this will use DSpace Context to refine Queries against Solr, thus providing a cleaner level access control on Search and Browse in DSpace. I've already voiced a big concern on the crippling effects of maintain two separate UI in parity within the core distribution of DSpace. I really do believe we should be only supporting One UI and push all others out into the modules community to be supported by those that continue to want to use them. When we welcomed Manakin in as a new user interface for DSpace, the majority of the feedback from the committers group was that the following would be he ideal path forward. 1.) to perceive JSPUI as primary and XMLUI as secondary in DSpace 1.5, 2.) in 1.6 to view XMLUI as primary and JSPUI as secondary. Thus the logical next step would be to 3.) properly decommission JSPUI in DSpace version 1.7 My further comment below.... On Mon, Mar 8, 2010 at 11:15 AM, Wendy J Bossons <[email protected]> wrote: > 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. Cocoon 2.2 and 3 alpha are Spring based. DSpace Service is Spring based but the application Contexts for XMLUI and DSpace Service do not interact directly, only via accessing the shared MBean. > 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. I would almost recommend taking a step back and reengineering the way the DSpace JSPUI uses the DSpace data model, throwing out all the custom tags in favor of JSTL/JSF/JSP. If the DSpace API were managed better as a Java Bean Data Model, we really wouldn't need Custom "DSpace" tags generating their own HTML... very bad. This clearly broke the separation of concerns with Content generation and presentation. > 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 favor a simpler and less resource intensive route > to achieve that. I agree, the XMLUI does an excellent job of ordering the information most important to the user first and then structuring that content with CSS. I'm not so concerned about the server load. This said there are a number of areas I do think the XMLUI can be improved. But I think that what we are working on now with DSpace Discovery is actually more significant than we let on. By introducing a new Search/Browse model with less "DSpace centric data modeling", we are freeing up the UI's to actually be much lighter. (1) We may not even pull DSpace Objects into Memory to render a view on content from them (i.e. a Solr record) and in some cases the rendering of the view to HTML in the browser may not even be done by a Java webapplication, let alone XMLUI/Cocoon. IE, AJAX/JSON and/or proxy/embedding in other website platforms. We need to revisit the DSpace REST api further from last years GSoC project as well, this tool, (and an addition of entity/search services based on Solr), I will suggest that, much like Aaron was recommending last year with 2.0 is more likely the future for interacting with DSpace with other UI platforms. I speculate it would be the next appropriate technology to enter into the Core, possibly displacing LNI in the long run for DSpace 1.7 >> 1) Interaction design: what is the succession of steps a user may be >> requested to do for a given task? This is part of the Cocoon Action/Javascript Continuation Tier. >> 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) ? This is what the XMLUI Aspect tier is doing. (Albiet a bit also in the theming layer) I'll just comment briefly that we can clean this up and push all generation into the Aspect tier and do away with using the METS/DIM call backing in the theming tier when customizing what content is actually delivered >> >> 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. Certainly present in XMLUI. > > 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... If we moved the METS/DIM stuff out of the theming layer and generated field level content in the Aspects we would be achieving this. > 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. Well, you know my opinion on more UI implementations Graham... that said... its is a good exercise to see if something better can arise from it. I hope if it were, we would take a lesson from the last year and choose one solution to support as primary in the future, rather than two or more simultaneously in the core of DSpace. Eventually I would hope the core actually doesn't have a UI in it and they are maintained wholly as separate projects within the "modules" community and assembled into the release distribution at release time. Cheers, Mark -- Mark R. Diggory Head of U.S. Operations - @mire http://www.atmire.com - Institutional Repository Solutions http://www.togather.eu - Before getting together, get t...@ther ------------------------------------------------------------------------------ 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
