[
https://jira.duraspace.org/browse/DSCR-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22579#comment-22579
]
Richard Rodgers commented on DSCR-26:
-------------------------------------
A couple of very quick reactions:
* work looks interesting and promising
* 'incomplete and a bit buggy' is not specific enough to react to. Could you
open JIRA tickets if you are aware of any bugs or other deficiencies, as is our
customary practice?
For example, I'm not clear on the trailing slash issue you raised - it is
required in XMLUI because the URL template we publish in the opensearch
document has a trailing slash (and that's simply because the OpenSearch doc
does it that way). It's also required in the JSPUI, but the front-end routing
code might slap one on - but this isn't an OpenSearch issue or bug that I can
see: it correctly handles URLs conforming to the published template.
* We need to ensure that OpenSearch is available even without Discovery, which
is an optional module - i.e. not add to its dependencies. We plan to run some
repos with, and some repos without Discovery but want OpenSearch for all.
> Add OpenSearch capabilities to Discovery enabled DSpace instances
> -----------------------------------------------------------------
>
> Key: DSCR-26
> URL: https://jira.duraspace.org/browse/DSCR-26
> Project: DSpace Discovery Module
> Issue Type: Improvement
> Reporter: Mark Diggory
>
> The default DSpace OpenSearch is incomplete and a bit buggy. But rather than
> fix it explicitly, I would prefer if we look to make Discovery become fully
> OpenSearch capable. This means that:
> a.) Discovery Creates its won OpenSearch Descriptor File with an accurate
> template URL that can be discovered.
> b.) Atom and RSS formated results are possible.
> c.) in the even that html is requested, the search is forwarded to the user
> interface.
> Likewise, rather than introducing an additional "/open-search" address for
> searches. Instead, an appropriate output format is rendered using Discovery
> on receiving the search request.
> To accomplish this I recommend rather than using Cocoon as the controller to
> process the incoming query request, that instead we utilize a new approach we
> are experimenting with in Dryad, here we have Placed SpringMVC in front of
> Cocoon and utilize it as the Controller in the request. In this case, rather
> than having Cocoon complete the query to solr, the controller would complete
> the query instead and pass it to an appropriate view as the model to be
> rendered.
> See the following code for more detail:
> Configuration of Webapplication to use SpringMVC instead of Default Cocoon
> Servlet.
> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/webapp/WEB-INF/web.xml
> Configuration of Cocoon to handle View Requests
> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/webapp/WEB-INF/spring-servlet.xml
> Cocoon Default Controller that resolves and forwards View requests to Cocoon
> when wanted.
> https://dryad.googlecode.com/svn/trunk/dryad/dspace/modules/xmlui/src/main/java/org/dspace/springmvc/CocoonForwardController.java
> New Controllers for Discovery woud be written that would complete the
> discovery search query and then forward the query results as a model to the
> View that would be processing the result.
> This will be immediately portable to the Freemarker UI project and possibly
> even be backported to the JSPUI project as well, setting the stage for
> Discovery to be available to that prototype.
> ----
> The architecture will be:
> 1. A SpringMVC Webapplication Project With a controller that support our
> query syntax and selection of an appropriate view technology from either
> ContentNegotiation and/or request Parameters or Pathnames.
> 2.) Use of the ContentNegotiationViewResolver to resolve the appropriate view
> to generate.
> 3.) Utilization of SpringMVC's default provided views to generate Atom, RSS,
> JSON formated outputs.
> 4.) Utilization of a CocoonView that internally forwards to cocoon for
> evaluating and rendering search results.
> A prototype should be authored and placed into a new project within
> /modules/dspace-discovery/trunk/dspace-discovery-webmvc
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
