But there's value in having something packaged within Solr itself, for demo purposes.
That would I suspect make it Java (like it or not!) And that would probably not make it very state-of-the art, unless it used jquery, with a very lightweight java portion, which would be possible. Upayavira On Tue, Dec 4, 2012, at 05:42 PM, Erik Hatcher wrote: > And basically that's what i had in mind with Prism here: > <https://github.com/lucidimagination/Prism> > Prism's very lightweight, uses Velocity (or not, any Ruby templating > technology available), and is entirely separate from Solr. Before that > there was Flare: > https://github.com/erikhatcher/solr-ruby-flare/tree/master/flare. > Prism is the approach I'd (obviously) take these days, and it's getting > some more attention, it looks like, soon. > > Blacklight and VuFind are much more richly capable. > > So there's options already out there, and surely many others that I don't > even mention. A new top-level wiki page seems warranted from this > discussion from <http://wiki.apache.org/solr/FrontPage> to list off all > the various front-ends available. > > Erik > > > > On Dec 4, 2012, at 12:11 , Upayavira wrote: > > > 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= > >> >
