Page History

Mirage 2 theme = Yes

Other themes = No

Apache Cocoon has very little adoption and support these days, and hasn't had a new release in many years.

Apache Cocoon could be considered forked locally by most of the third party projects that utilize it.

Personal opinions on DSpace XMLUI:

• Tim Donohue: My personal opinion is that, as it currently exists, the XMLUI should not be the choice going forward as it is based on an outdated, nearly obsolete framework (Apache Cocoon). In my opinion, it would require abandoning Apache Cocoon to be in consideration.
• Graham Triggs Drawbacks are size of the framework, complexity of the framework, lack of adoption and support for Apache Cocoon.
• Mark Diggory: Note, since DSpace 1.8 XMLUI also provides Spring WebMVC context and control (whose viewing technology is still Cocoon). I consider the points REST-friendly and Rapid Dev friendly to be subjective, we to rapid dev in Cocoon often, but it certainly is not a Rails, Grails, Play experience). Also note, Considerable parts of JSPUI were copied to XMLUI and placed into Cocoon Action, Matcher and Transformer classes, this UI logic could be compartmentalized separate from both UI and used across all web-applications including dspace-rest. Examples include authentication session management, request management, context management, resource resolution, even parts of Submission and Workflow _{( jspui   , xmlui )} . An ideal path forward would migrate these features out of xmlui/jspui, where possible, make them UI agnostic, and place them into dspace-api.

Personal opinions on DSpace JSPUI:

• Tim Donohue : My personal opinion is that, as it currently exists, the JSPUI should not be the choice going forward, as its codebase is extremely dated and not easy to work with (despite the recent UI redesign). In my opinion, it would require a major overhaul to be in consideration. To be clear, this doesn't mean JSPUI is "dead", just that it would need a lot of cleanup work / redesign if we want to go this route.
• Graham Triggs : A rewrite would be essential - preferably moving away from JSP to a templating engine, even if not using a recognized MVC framework. However, the benefits of being based on a widely known technology and having a small footprint are apparent.
• Mark Diggory : Any move to repurpose or evolve of JSPUI should include a rewrite of certain features: the DSpace JSP tag lib should not include html, beans and JSTL should be leveraged instead. See comments regarding XMLUI/JSPUI consolidation above.

Personal opinions on Spring MVC Framework:

• Mark Diggory : As a core technology of many of the frameworks below, Spring MVC has a strong uptake. As with many of the frameworks below, we are not necessarily locked into the view technology choices for all our user base. We may set the stage for a migration to frameworks below by first adopting a practice of using Spring MVC in both the XMLUI and JSPUI. See comments above in XMLUI
• Chris Wilper : Having used Spring MVC on several projects, I've seen cases where it has driven a pure REST/HATEOAS API, as well as HTML-producing endpoints (backed by XSLT transformation, velocity/freemarker templates, etc.). It has been around for quite a while and has a huge community behind it. A related project is Spring Web Flow, which looks a possible alternative to Cocoon's webflow for orchestrating certain user tasks, currently used by XMLUI.

Personal opinions on Play Framework:

• Graham Triggs I had a brief play with it a while ago. It's a neat technology, but has drawbacks in being more tailored to Scala than Java, and lacking documentation. It's also very dependent on using the Play toolset, even though in the background it can use Maven to manage dependencies, there would be a lack of synergy between front end and back end development, which might be an issue.

Not yet. It's still very new (1.0.0 released in 2014).

However, the Spring IO platform itself is very widely used, and Spring Boot seems to have a lot of activity on GitHub, Stackoverflow, etc.

Note, Grails is part of the Spring I/O application stack. Appears to run directly on Boot in this case.

Personal opinions on Spring Boot:

• Graham Triggs Initial tests are quite positive. Obviously integrates very well with the Spring ecosystem, yet you can easily create a 'standard' Maven project for the application. Uses many templating engines (my preference is for Freemarker).
• Mark Diggory   : Mostly a Spring runtime container, will support other views, does not directly addresses the two UI problem. Introduces a larger scale re-architecture project than just UI consolidation.

Personal opinions on Ruby on Rails:

• Graham Triggs Clean separation of front end and back end (via REST calls), will add latency and may cause problems for switching between front and back end development. Also, hosting concerns (JRuby vs separate Ruby and Java containers)
• Mark Diggory   : Much more than a UI framework, opens the door to large questions concerning rewriting DSpace, takes us away from a single java technology stack

Not worldwide, but has a growing following in libraries, etc.

The base technology, Ruby on Rails is widely adopted

Hydra doesn't currently "work" with DSpace.

It would likely be a major endeavor to either migrate DSpace into a "Hydra Head" web application or "port" Hydra as a UI on top of DSpace's underlying architecture.

However, if we decided on the former (create a DSpace-like Hydra Head), there are members of the Hydra Community who are currently striving to do that same thing.

Personal opinions on Hydra:

• Mark Diggory  : Much more than a UI framework, in either case its a larger migration path and endeavor than consolidating DSpace onto a single UI technology. In either of the proposed cases it does not solve the immediate need for a single UI.

Personal opinions on Grails:

• Graham Triggs Pivotal (the main commercial developer) has recently announced that it is no longer sponsoring Groovy / Grails. This is apparently because of an increasing amount of community support, however, it may point to concerns in the future.
• Mark Diggory  : Grails has its own DispatchServlet (much like XMLUI did with Cocoon prior our modifications) I
• To grok grails as quickly as possible its Ruby on Rails for Java: This means its more than a UI technology, we would be rewriting much of DSpace in the process. Example of Grails application in three pages, you generate the entire application stack, from Hibernate to UI in several commands. Again, this leverages WebMVC and the UI technology shown in the example is Spring WebMVC+JSP, but it supports other view technologies like Grails Server Pages. Seems to be REST/AJAX friendly. However, IMO, we are back to rewriting core DSpace to implement DSpace as a Grails App.

Personal opinions on JQuery UI:

• Mark Diggory   : Does not address the Server side functionality that is needed to maintain use of this technology, I would exclude from list as a supporting library of functionality found in UI technology stacks in other technologies in this list.
  
  

Personal opinions on Backbone.js:

• Art Lowel (Atmire) Backbone is too low level imo. You still have to write a lot of boilerplate code yourself. We should probably replace it with one of the more modern JS MV* frameworks as alternatives to ember js, like angular, knockout or react
  
• Mark Diggory  : Does not address the Server side functionality that is needed for persistence, a full suite of REST services would need to be present, questions would need to be answered regarding if workflows are managed as client side activities or server side activities.

Personal opinions on Ember.js:

• Art Lowel (Atmire) Ember is very "opinionated" which is great to guide you in to using best practices to solve common problems. But it can get tricky if you need to solve an uncommon problem and you have to fight the system to make it work. However I'd like to add a +1 for ember.
  
• Mark Diggory  : Does not address the Server side functionality that is needed for persistence, a full suite of REST services would need to be present, questions would need to be answered regarding if workflows are managed as client side activities or server side activities.