I guess it is important to distinguish between the VelocityResponseWriter and the /browse request handler. I suspect you are referring to the latter.
The /browse interface is both useful and problematic. It is useful because it allows users to interact with their searches and results in a more intuitive way, doing useful things like viewing parsed queries, explains results, and various types of searches and faceting. The problem with it is that it isn't always obvious that it is intended as an example, rather than as a fully functioning user interface, particularly as one that a user might extend for their own use. The /browse request handler lacks both security (you can't prevent folks wiping your index) and lacks a controller in an MVC sense. So, I guess my question is, what is /browse for, and how can we make it more clear that that is its purpose? And whether the HTML should be generated client or server side - that's quite a debate. I went with client side rendering merely to follow the approach used by the existing admin UI, although there is an added benefit of it not requiring any special config in solrconfig.xml if it just uses json. I agree that velocity is just a templating language and is no way at fault. E.g. I remember a really effective use of XSLT to render RSS direct out of Solr - worked exceptionally well. Upayavira On Fri, Dec 14, 2012, at 05:15 PM, Erik Hatcher wrote: > There's absolutely nothing inherently wrong with using Velocity with lean > templating to render responses from Solr. It's just a templating > technology. > > What you've done in your patch is replace the (IMO, and perhaps I'm the > minority here?) clean Velocity template approach with some > JavaScript/Ajax, in a much more obscure way to comprehend what is going > on from UI to response rendering. > > But, in your tabbed approach (something I've pondered and built > prototypes of over the years), the HTML could (/should!) be rendered via > Velocity templates - easy enough and much cleaner than JavaScript > templating and actually showcases a better best practice as an example > anyway, that being generating HTML on the server rather than on the > client necessarily. I'm of course pretty opinionated on these topics, > perhaps just for old times sake clinging on to what seems like a clean > way to do stuff. Velocity itself should not get a bad rap here, since > it's a top notch technology in and of itself. > > I don't disagree that the admin UI ad-hoc querying ought to have the > tabbed approach, so +1 to that. > > Maybe I'll get my wish for Xmas this year... loads of quiet computer time > to roll up my sleeves and tackle some of the many TODOs I have on the > Velocity response writer, Prism, and so on. There's good stuff there, so > I'll aim to do lots of polishing to get this stuff more presentable than > ever. > > Erik > > > On Dec 7, 2012, at 19:33 , Upayavira wrote: > > > I realised yesterday what useful about /browse, and why it is wrong as > > it is. > > > > The browse interface is a good way for a newcomer to explore some > > aspects of the query response without having to pour through lots of XML > > or JSON. It gives them a visual representation of their query result. > > > > While that's useful, /browse using Velocity also gives the impression > > that using Velocity for this purpose is a good idea, which it so clearly > > isn't. > > > > My thought, then, is that we should migrate the functionality of /browse > > over to the admin UI. > > > > My thoughts are that the query pane should, on the left, have 'simple' > > and 'advanced' tabs. The simple tab gives a more conventional search > > interface, whereas the advanced tab shows whats there currently. > > > > On the right, along the top you'd have buttons for XML, JSON, etc. One > > other button, HTML, would display the results of your search a bit more > > prettily, more like a conventional search results, or at least as much > > like that as possible when you really don't know much about what data > > you're getting back. > > > > To put my money where my mouth is, I've uploaded a patch to JIRA[1] with > > a first pass at what I mean. > > > > Thoughts/comments welcome. > > > > Upayavira > > [1] https://issues.apache.org/jira/browse/SOLR-4157 > > > > On Tue, Dec 4, 2012, at 10:41 PM, Upayavira wrote: > >> 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= > >>>>> > >>> >
