Re: How to change Solr UI
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=
Re: How to change Solr UI
(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=
Re: How to change Solr UI
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
Re: How to change Solr UI
It's a shame wt=velocity gets a bad rap because /update isn't out of the box strict with the HTTP/RESTful scene. A delete should be a DELETE of some sort. There are 3rd party standalone apps. There was even a standalone ruby app (flare) that was once upon a time in Solr's svn, but really the Solr committers can't be expected to maintain all those various examples and keep them up to date and working, so best to keep them 3rd party IMO. We've got Blacklight, VuFind, and all sorts of other front-ends out there with their own vibrant communities. I'm -1 for removing VW (it's contrib plugin as it is already, just like /update/extract). /browse certainly could use a cleaning up / revamping, but it's good stuff if I do say so myself and very handy to have available for several reasons*. Let's try not to conflate wt=velocity with /update being more easily dangerous than it probably should be. But let's also be clear always that Solr is meant to be behind the firewall as it's primary and default place in the world. Erik * One I'll share: There is a real-world use case of a (relatively big) company using wt=velocity to generate e-mail (for saved searches) texts very conveniently in a backend environment and very high speed, no other technologies/complexities needed in the mix but Solr and a little custom templating. On Dec 3, 2012, at 20:58 , Jack Krupansky wrote: It is annoying to have to repeat these explanations so much. Any serious objection to removing the VW UI from Solr proper and replacing it with a standalone app? I mean, Solr should have PHP, python, Java, and ruby example apps, right? -- Jack Krupansky -Original Message- From: Iwan Hanjoyo Sent: Monday, December 03, 2012 8:28 PM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
Re: How to change Solr UI
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. -- Jack Krupansky -Original Message- From: Erik Hatcher Sent: Tuesday, December 04, 2012 5:23 AM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI It's a shame wt=velocity gets a bad rap because /update isn't out of the box strict with the HTTP/RESTful scene. A delete should be a DELETE of some sort. There are 3rd party standalone apps. There was even a standalone ruby app (flare) that was once upon a time in Solr's svn, but really the Solr committers can't be expected to maintain all those various examples and keep them up to date and working, so best to keep them 3rd party IMO. We've got Blacklight, VuFind, and all sorts of other front-ends out there with their own vibrant communities. I'm -1 for removing VW (it's contrib plugin as it is already, just like /update/extract). /browse certainly could use a cleaning up / revamping, but it's good stuff if I do say so myself and very handy to have available for several reasons*. Let's try not to conflate wt=velocity with /update being more easily dangerous than it probably should be. But let's also be clear always that Solr is meant to be behind the firewall as it's primary and default place in the world. Erik * One I'll share: There is a real-world use case of a (relatively big) company using wt=velocity to generate e-mail (for saved searches) texts very conveniently in a backend environment and very high speed, no other technologies/complexities needed in the mix but Solr and a little custom templating. On Dec 3, 2012, at 20:58 , Jack Krupansky wrote: It is annoying to have to repeat these explanations so much. Any serious objection to removing the VW UI from Solr proper and replacing it with a standalone app? I mean, Solr should have PHP, python, Java, and ruby example apps, right? -- Jack Krupansky -Original Message- From: Iwan Hanjoyo Sent: Monday, December 03, 2012 8:28 PM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
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
Re: How to change Solr UI
I have been mulling on this. The browse UI is getting a little out of date, and has interesting 'features' such as only showing a map for a document if the document has a 'name' field, which makes no real sense at all. Apart from renovating the UI of browse, or possibly replacing it with something more modern based upon the new admin UI technology, it would make sense to add a 'disclaimer' somewhere prominent on the browse interface - title it 'Solr Demo' or 'Solr Prototype', and add a link to a wiki page that explains *why* you shouldn't use this in production. Apart from the security issues already mentioned there's the MVC side - you have a model and a view, but no controller, thus it becomes hard to build anything useful very quickly. I'd happily hack disclaimers into place if considered useful. Upayavira On Tue, Dec 4, 2012, at 01:21 PM, 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. -- Jack Krupansky -Original Message- From: Erik Hatcher Sent: Tuesday, December 04, 2012 5:23 AM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI It's a shame wt=velocity gets a bad rap because /update isn't out of the box strict with the HTTP/RESTful scene. A delete should be a DELETE of some sort. There are 3rd party standalone apps. There was even a standalone ruby app (flare) that was once upon a time in Solr's svn, but really the Solr committers can't be expected to maintain all those various examples and keep them up to date and working, so best to keep them 3rd party IMO. We've got Blacklight, VuFind, and all sorts of other front-ends out there with their own vibrant communities. I'm -1 for removing VW (it's contrib plugin as it is already, just like /update/extract). /browse certainly could use a cleaning up / revamping, but it's good stuff if I do say so myself and very handy to have available for several reasons*. Let's try not to conflate wt=velocity with /update being more easily dangerous than it probably should be. But let's also be clear always that Solr is meant to be behind the firewall as it's primary and default place in the world. Erik * One I'll share: There is a real-world use case of a (relatively big) company using wt=velocity to generate e-mail (for saved searches) texts very conveniently in a backend environment and very high speed, no other technologies/complexities needed in the mix but Solr and a little custom templating. On Dec 3, 2012, at 20:58 , Jack Krupansky wrote: It is annoying to have to repeat these explanations so much. Any serious objection to removing the VW UI from Solr proper and replacing it with a standalone app? I mean, Solr should have PHP, python, Java, and ruby example apps, right? -- Jack Krupansky -Original Message- From: Iwan Hanjoyo Sent: Monday, December 03, 2012 8:28 PM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
Re: How to change Solr UI
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=
Re: How to change Solr UI
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=
Re: How to change Solr UI
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=
Re: How to change Solr UI
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=
Re: How to change Solr UI
Hi Romita, In my opinion, if you are new to Solr, you can start learning from Solritas. Solritas uses Apache Velocity, a templating language, CSS and JQuery to manage it looks and behavior. Besides that you can write a custom SearchComponent inside the /browse SearchHandler to add more functionality to your search application. Kind regards, Hanjoyo On Mon, Dec 3, 2012 at 4:35 PM, Romita Saha romita.s...@sg.panasonic.comwrote: Hi, I want to change the Solr UI. As far as i understand, Solritas is just for prototyping, where I can change the UI according to a predefined template (Velocity) and cannot add on any additional functionality to that page. How can I change the Solr UI otherwise. Any guidance would be appreciated. Thanks and regards, Romita
Re: How to change Solr UI
Adding to what Iwan said, I want to be sure you're not confusing prototyping with a full-fledged application. The Velocity code included is mostly intended as a rapid-prototyping vehicle. There are significant security issues if you try to use it as your user-facing application, be sure you trust your users if you go down this route. But to change it, see the Apache velocity project, and the code in solr home/conf/velocity. Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http://solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Most installations use a middle layer between Solr and the user that controls access. Best Erick On Mon, Dec 3, 2012 at 5:01 AM, Iwan Hanjoyo ihanj...@gmail.com wrote: Hi Romita, In my opinion, if you are new to Solr, you can start learning from Solritas. Solritas uses Apache Velocity, a templating language, CSS and JQuery to manage it looks and behavior. Besides that you can write a custom SearchComponent inside the /browse SearchHandler to add more functionality to your search application. Kind regards, Hanjoyo On Mon, Dec 3, 2012 at 4:35 PM, Romita Saha romita.s...@sg.panasonic.com wrote: Hi, I want to change the Solr UI. As far as i understand, Solritas is just for prototyping, where I can change the UI according to a predefined template (Velocity) and cannot add on any additional functionality to that page. How can I change the Solr UI otherwise. Any guidance would be appreciated. Thanks and regards, Romita
Re: How to change Solr UI
Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
Re: How to change Solr UI
It is annoying to have to repeat these explanations so much. Any serious objection to removing the VW UI from Solr proper and replacing it with a standalone app? I mean, Solr should have PHP, python, Java, and ruby example apps, right? -- Jack Krupansky -Original Message- From: Iwan Hanjoyo Sent: Monday, December 03, 2012 8:28 PM To: solr-user@lucene.apache.org Subject: Re: How to change Solr UI Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
Re: How to change Solr UI
That's only one example, there are others, stream.body=deleteidblah/id/delete. or deletequeryid:*/query/delete Jack's comment is well taken, consider a real middleware application. Best Erick On Mon, Dec 3, 2012 at 5:28 PM, Iwan Hanjoyo ihanj...@gmail.com wrote: Note that Velocity _can_ be used for user-facing code, but be very sure you secure your Solr. If you allow direct access, a user can easily enter something like http:// solr/update?commit=truestream.body=deletequery*:*/query/delete. And all your documents will be gone. Hi Erickson, Thank you for the input. I'll notice and filter out this url. * http:// solr/update?commit=truestream.body=deletequery*:*/query/delete Kind regards, Hanjoyo
