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. 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 pe...@longsight.com p: 740-599-5005 x809 On Mon, Aug 3, 2015 at 11:21 AM, Brown, Jacob <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 > 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
