Hi Peter, Thanks for the comments and feedback!
I think your "business services" layer is exactly what I meant: a set of utilities (e.g., POJOs) that may or may not need to read the HttpServletRequest object, that could be used to help build up search or browse interfaces for any web framework (e.g., something implementing the servlet API). I think the REST framework would be tangential to this; this would be Java code that could be used by REST, XMLUI, JSPUI, etc. I think REST is great and I think Rails in front of REST would be interesting. However, I don’t quite see why, for example, XMLUI would use REST to retrieve recent submissions, when it could just use a Java method to do so? I think it would be ideal to put these utilities in shared Java code, and then each framework would have a thin wrapper around them according to their specific needs. Jacob From: Monika C. Mevenkamp [mailto:moni...@princeton.edu] Sent: Monday, August 3, 2015 1:43 PM To: Peter Dietz <pe...@longsight.com> Cc: dspace-tech@lists.sourceforge.net Subject: Re: [Dspace-tech] Generic DSpace servlet/webapp utilities? Peter 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 — 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 <pe...@longsight.com<mailto:pe...@longsight.com>> 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. https://trydspace.longsight.com/rest/collections/18?expand=all Disco is pretty cool. It looks nice, its very clean, and IT WORKS. After starting the container, the instructions could mention browsing to http://localhost:3000<http://localhost:3000/>. 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 org.dspace.app.xmlui or org.dspace.app.webui (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 Longsight www.longsight.com<http://www.longsight.com/> pe...@longsight.com<mailto:pe...@longsight.com> p: 740-599-5005 x809<tel:740-599-5005%20x809> On Mon, Aug 3, 2015 at 11:21 AM, Brown, Jacob <j.h.br...@tcu.edu<mailto:j.h.br...@tcu.edu>> wrote: Hi all, I’m working (slowly) on a simple alternate web frontend for DSpace: https://github.com/kardeiz/disco.* 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 RecentSubmissionUtils<https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/aspect/discovery/recentSubmissions/RecentSubmissionUtils.java>. 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 org.dspace.app.util.Util. 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— Thanks, 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 https://github.com/kardeiz/disco cd disco export DSPACE_DIR=/path/to/dspace ./sbt container:start Disclaimers: 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 DSpace-tech@lists.sourceforge.net<mailto:DSpace-tech@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net<mailto:DSpace-tech@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
------------------------------------------------------------------------------
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
