Or, maybe integrate /browse with the Solr Admin UI and give it a graphic
treatment that screams that it is a development tool and not designed to be
a model for an app UI.
And, I still think it would be good to include SOME example of a prototype
app UI with Solr, to drive home the point of "here is [an example of] how
you need to separate UI from Solr."
-- Jack Krupansky
-----Original Message-----
From: Erik Hatcher
Sent: Tuesday, December 04, 2012 9:29 AM
To: solr-user@lucene.apache.org
Subject: Re: How to change Solr UI
On Dec 4, 2012, at 08:21 , Jack Krupansky wrote:
"let's also be clear always that Solr is meant to be behind the firewall"
Absolutely, but we are NOT doing that when we provide the Velocity-based
/browse UI.
Erik, your email example sounds reasonable, so if you want to substitute
something like that for the /browse handler, fine. As you point out, it is
not Velocity per se, but the /browse UI that results in a lack of clarity
about Solr being meant to be behind the firewall.
Point taken about being clear about this. But I disagree about removing
/browse. It's useful, even if misunderstood/abused by some. If there are
spots where we need to be clearer about what it is that is being rendered,
how it's rendered, and the pros/cons to it, then let's see about getting it
mentioned more clearly.
But do keep in mind that something like this example: having Solr return
suggestion lists as plain text suitable for suggest interfaces rather than
having it return JSON or XML and having a middle tier process it when all
you need is a plain list or some CSV. It's quite fine and sensible to use
wt=velocity "behind the firewall" too, even /browse as-is. Same as with the
XSL transformation writing capability.
Erik=
