That's an interesting take. I agree that Solr needs *something* for folks to use. It is unfortunate that Solr actually has a functioning HTTP infrastructure, because it then makes less sense to build an alternative one up. E.g. How about:
http://localhost:8983/solr <- admin UI http://localhost:8983/browse <- separate browse webapp It would be a separate app that runs as another wepapp, accessing Solr via HTTP just as any other app would. It could still use Velocity, but would demonstrate that you shouldn't integrate your app with Solr. A minimal dependency app for demonstration purposes only. Upayavira On Tue, Dec 4, 2012, at 02:37 PM, Jack Krupansky wrote: > 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= >
