Disco ?
Rails in front of REST ?
What can it do ?
Where can I see it ?

I agree - a UI in front of rest will enforce at least some code layering  -
although it is not a full solution to avoiding code replication for higher 
level operations, aka controllers / business logic / workflow ...


Monika Mevenkamp
Digital Repository Infrastructure Developer
Phone: 609-258-4161
333C 701 Carnegie, Princeton University, Princeton, NJ 08544

On Aug 3, 2015, at 2:03 PM, Peter Dietz 
<<>> wrote:

My first thought nowadays when I hear "generic", is REST. Otherwise, any *.util 
classes will need to deployed by some webapp. Independent of XMLUI/JSPUI. 
Not-A-UI? To actually accomplish REST-ification, would we make XMLUI/JSPUI 
depend on REST to accomplish some things? Such as recent submissions to a 
collection, that data comes from rest?

/rest/collections/:id?expand=all will give you data of recent items. Probably 
not all the metadata (or bitstreams) to display that, and the thumbnails 
though. But... If that was needed, then REST could be altered to support that.

Disco is pretty cool. It looks nice, its very clean, and IT WORKS. After 
starting the container, the instructions could mention browsing to 

I did run into a browse bug.
Home - Refine Search Author (pick one) - Sort By Date (no results show)...

There is a ton of overlap between duplicated codes in the UI's. Sometimes it is 
identical blocks (an automated code smell detector might be able to find this), 
or sometimes a block might differ with one line, so it ends up being a method 
in JSPUI, and a method in XMLUI. I think we had been calling this general idea 
of cleaning things, adding a "business services" layer.

The direction that we want to steer DSpace is to refactor this common code out 
of the UI's, and make it reusably usable from dspace-api. Exposing it as a 
servlet, not sure. But we would want to simplify the code base, and build 
better, more capable user experiences. So, prototypes such as yours are perfect 
to toss into the ring too. Its not decided as to what the better route would be 
(webapp built in DSpace, or external webapp that talks to DSpace), but the 
concept of a "turnkey" DSpace that just works with a consistent experience has 
been DSpace's strength for a while. If you run into any shortcomings with what 
DSpace exposes, you might be able to add a PR to have some common DSpace method 
providing the functionality, without depending on or (JSPUI). But, perhaps one type of place that might be a 
more proper place to look would be org.dspace.content.service.ItemService...

Peter Dietz
p: 740-599-5005 x809<tel:740-599-5005%20x809>

On Mon, Aug 3, 2015 at 11:21 AM, Brown, Jacob 
<<>> wrote:
Hi all,

I’m working (slowly) on a simple alternate web frontend for DSpace:*

I was thinking that it would be nice if DSpace provided some 
implementation-agnostic utilities for a generic HttpServlet context.

For example, XMLUI and JSPUI provide their own wrappers for things like 
browsing, searching, recent submissions, etc., but in many cases the code used 
is very similar and not dependent on the specific framework. It would be 
possible to abstract out a lot of the functionality of these wrappers into 
utility methods that have signatures like `HttpServletRequest req, 
HttpServletResponse resp`.

As a specific example, consider 
 There is no reason this class has to be XMLUI specific; if it was in some 
shared package, JSPUI or any other framework could just use it directly to 
generate a list of recent submissions for a community or collection.

There are already a couple of servlet-related utilities in dspace-api at

I don’t know if anything like this has ever been discussed, or if there are 
reasons it wouldn’t work. I know it would require a lot of collaboration 
between JSPUI and XMLUI developers. I guess this is something that should go on 
a DSpace “wishlist”; I apologize if this isn’t the correct place for that—


Jacob Brown

* In case anyone wants more information: this application is written in Scala 
and uses:

•         the DSpace API (5.x) for working with a local DSpace repository

•         Jersey for request routing (and not much else)

•         Twirl for HTML templating

•         xsbt-web-plugin for running in development and WAR packaging

•         Bower and Gulp for frontend asset management

In a little over 700 lines of Scala and a handful of HTML templates, this 
application provides a good portion (but certainly not all) of the 
non-administrative functionality of a normal XMLUI site, including home, 
community, collection, and item view pages, and search and browse interfaces 
(including sidebar facets).

Getting started should be as easy as:

git clone
cd disco
export DSPACE_DIR=/path/to/dspace


This application is under active development and is not a finished/polished 
product. Parts of it may be untested or in need of improvement. While this 
application should be mostly “read-only” in relation to your local DSpace 
installation, I would recommend against running it on a production server at 
this point. Use at your own risk.


DSpace-tech mailing list<>
List Etiquette:

DSpace-tech mailing list<>
List Etiquette:

DSpace-tech mailing list
List Etiquette:

Reply via email to