...
- Conclusion: Our DSpace Committers group can only reasonably build/support/maintain a single, out-of-the-box DSpace UI.
- Please note this does NOT state there should only be ONE UI (as noted above there are some advantages to multiple UIs). It simply states that there will only be one out-of-the-box UI.
- If there are enough developers/institutions who see an ongoing need for a secondary UI, they are welcome to build, support and maintain a secondary, optional UI with their own, separate group of developers/committers.
- A sidenote of sorts: If a secondary "committers group" were to form around a secondary UI, it may someday make sense to "split" the "DSpace Committers Group" into several "sub-teams": One team in charge of the underlying API / REST API, one team in charge of the primary, out-of-the-box UI, one team in charge of the secondary UI (if any). These teams would likely have some overlapping members, but they'd each be self-sufficient and more tailored to the needs of each individual sub-modules.
- Opinions? Please feel free to add +1 / 0 / -1 to this conclusion, and any comments you may have
- I AGREE: We only should maintain a single, out-of-the-box DSpace UI. If a secondary UI is built (or continues to be maintained), it should be maintained by a separate team of committers / developers (and therefore become a separate project or organization in GitHub).
- +1 Tim Donohue
- +1 Bram Luyten (Atmire)
- +1 Mark Diggory (however, with the caveat that UI application logic be integrated into DSpace core such that additional UI may be easily authored and maintained externally)
- (add your name here, if you agree with the above conclusion. Feel free to also add additional thoughts/comments)
- I DISAGREE: We should continue to support/maintain multiple out-of-the-box DSpace UIs with our existing DSpace Committers Team
- (add your name here, if you disagree with the above conclusion. Feel free to also add additional thoughts/comments)
- I AGREE: We only should maintain a single, out-of-the-box DSpace UI. If a secondary UI is built (or continues to be maintained), it should be maintained by a separate team of committers / developers (and therefore become a separate project or organization in GitHub).
...
UI Framework | Languages / Technologies | Widely Adopted? | Ease of Customization | Responsive web design support | HTML5 support | REST-friendly | Faceted/Filtered Search/Browse friendly | Rapid Development friendly | Third-party plugin ecosystem | Notes |
---|---|---|---|---|---|---|---|---|---|---|
Existing DSpace XMLUI | Java, Apache Cocoon,XSLT, also leverages Spring WebMVC | No | Not really (except maybe at Bootstrap level with Mirage2) | Mirage 2 theme = Yes Other themes = No | No | No | Yes | No | 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:
| ||||||||||
Existing DSpace JSPUI | Java, JSPs | No | Not really (again, except maybe at Bootstrap level with Mirage2) | Yes | A few areas (e.g .HTML5 upload), but not overall | No | Yes | No | No | The JSPUI codebase is approximately 13+ years old, despite some recent work to update it to use Bootstrap. |
Personal opinions on DSpace JSPUI:
| ||||||||||
Play! Framework | Java, Scala | Yes, some major sites use it according to Wikipedia | Yes, can be used with Bootstrap | Yes | Yes, has a modules repository | |||||
Personal opinions on Play Framework:
| Spring Boot | Java | Yes, it's built as a rapid development friendly version of Spring | Built on Spring, so you can use other Spring projects | ||||||
Personal opinions on Spring Boot:
| ||||||||||
Ruby on Rails | Ruby | Yes | Yes, has a Rails Bootstrap app, plus many gems | Yes | Yes, in form of Rails plugins & Ruby gems | |||||
Personal opinions on Ruby on Rails:
| Hydra Framework | Ruby on Rails, Fedora, Blacklight | Not worldwide, but has a growing following in libraries, etc. The base technology, Ruby on Rails is widely adopted | Yes (well, Sufia uses Bootstrap) | Yes (uses REST to communicate with Fedora) | Yes (Blacklight) | Yes | Yes, because it's Ruby on Rails, you often can use Rails plugins and/or Ruby gems | Hydra doesn't currently "work" with DSpace.||
| ||||||||||
Existing DSpace JSPUI | Java, JSPs | No | Not really (again, except maybe at Bootstrap level with Mirage2) | Yes | A few areas (e.g .HTML5 upload), but not overall | No | Yes | No | No | The JSPUI codebase is approximately 13+ years old, despite some recent work to update it to use Bootstrap. |
Personal opinions on DSpace JSPUI:
| ||||||||||
Spring WebMVC | Java, Many View Technologies (JSP,FreeMarker, Groovy, etc) | Yes | Yes | Dependent on View technology | Dependent on View technology | Dependent on View technology | Dependent on View technology | Dependent on Framework choices | No | Many java based frameworks utilize Spring MVC under the hood, |
Personal opinions on Spring MVC Framework:
| ||||||||||
Play! Framework | Java, Scala | Yes, some major sites use it according to Wikipedia | Yes, can be used with Bootstrap | Yes | Yes, has a modules repository | |||||
Personal opinions on Play Framework:
| ||||||||||
Spring Boot | Java | 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. | Yes, it's built as a rapid development friendly version of Spring | Built on Spring, so you can use other Spring projects | ||||||
Personal opinions on Spring Boot:
| ||||||||||
Ruby on Rails | Ruby | Yes | Yes, has a Rails Bootstrap app, plus many gems | Yes | Yes, in form of Rails plugins & Ruby gems | |||||
Personal opinions on Ruby on Rails:
| ||||||||||
Hydra Framework | Ruby on Rails, Fedora, Blacklight | Not worldwide, but has a growing following in libraries, etc. The base technology, Ruby on Rails is widely adopted | Yes (well, Sufia uses Bootstrap) | Yes (uses REST to communicate with Fedora) | Yes (Blacklight) | Yes | Yes, because it's Ruby on Rails, you often can use Rails plugins and/or Ruby gems | Hydra doesn't currently "work" with DSpace. 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:
| ||||||||||
Grails | Groovy (based on Java), Also based on Spring WebMVC | Yes, large number of sites using Grails listed on website | Yes, has several Bootstrap plugins | Yes | Yes | Yes, has a plugins repository | ||||
Personal opinions on Grails:
| ||||||||||
Personal opinions on Hydra: | ||||||||||
Grails | Groovy (based on Java) | Yes, large number of sites using Grails listed on website | Yes, has several Bootstrap plugins | Yes | Yes, has a plugins repository | |||||
Personal opinions on Grails:
| ||||||||||
JQuery UI | Javascript | Yes | Yes, e.g. there is a JQuery UI theme for Bootstrap | Yes | Yes, has a plugin repository | |||||
Personal opinions on JQuery UI:on JQuery UI:
| ||||||||||
(Javascript with RESTful JSON interface & Model-View-Presenter) | Javascript | Yes, large number of major sites listed on Wikipedia & their homepage | Yes, or at least you can use it in conjunction with Bootstrap. | Yes | Yes | Yes, has plugins and extensions | Designed for developing "single page web applications". It could prove difficult to use with DSpace because of the complexity of a repository system. | |||
Personal opinions on Backbone.js:
| ||||||||||
(Client-side Javascript web application using MVC) | Javascript | Yes, see their list of users on website | Yes, can use in conjunction with Bootstrap, e.g. https://indexiatech.github.io/ember-components/#/overview | Yes | Yes | Yes, there's an "addon" repository | Uses Grunt, Bower, NPM (all of which are also in use by Mirage 2 theme) | |||
Personal opinions on Ember.js:
|