You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Erik Hatcher <er...@gmail.com> on 2011/12/09 22:30:50 UTC
VelocityResponseWriter's future
So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
I appreciate your candid thoughts on this.
Erik
Re: VelocityResponseWriter's future
Posted by "David Smiley (@MITRE.org)" <DS...@mitre.org>.
Erik,
The /browse UI pages have definitely gotten a bit long in the tooth, to
the point that it's a maintenance nightmare IMO. Perhaps it was inevitable
given the nature of the technology; it would be the same situation with
JSP/ASP/PHP. FWIW, in my experience with Endeca (a Solr competitor) their
JSP based sample app was even worse of a maintenance nightmare. I demo what
Solr can do using /browse unmodified, but I otherwise don't use it. I prefer
AJAX-Solr for a variety of reasons:
* It's a technology you could not only start with but ultimately go to
production with, particularly in corporate environments where the
denial-of-service risk isn't as great as the public web.
* Browser centric web development is on the rise, with a benefit of being
agnostic of the middle tier technology stack which can tend to completely
isolate different pools of developers (e.g. a Java guy vs RoR guy vs...)
* It's a framework, yet its light weight and doesn't get in my way. I treat
it as sort of a template framework that I modify as I see fit for my app.
There's not a lot to understanding how it works. No magic.
That said, I think AJAX-Solr is not quite where it needs to be. I'd like to
see it move into the role that the /browse UI has in demoing a large variety
of Solr's functionality against a known sample data set. It doesn't yet
have all the "widgets" to do that. I also think it could strongly benefit
from using a JavaScript template technology like jQuery templates which I've
used to great success with AJAX-Solr in place of AJAX-Solr's "Theme" junk.
Sorry if this turned into an AJAX-Solr advertisement but it is my opinion
that adopting AJAX-Solr for the role /browse has is ultimately a better
thing than a Velocity/JSP/PHP/ASP page based UI.
~ David Smiley
-----
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context: http://lucene.472066.n3.nabble.com/VelocityResponseWriter-s-future-tp3574147p3574904.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: VelocityResponseWriter's future
Posted by Paul Libbrecht <pa...@hoplahup.net>.
Le 10 déc. 2011 à 02:56, Erik Hatcher a écrit :
>> It's fast and easy but its testing ability is simply... unpredictable.
>
> I'm not sure I get what you mean by the testability though. Could you clarify? Taken a bit literally with the VRW, there's this in a test case:
Feeling sure of whether boo is going to be output in the snippet below.
#if(blablabla)
boo!
#end
is going to be executed.
Sorry for the confusion, no (unit-, integration-) testing here.
paul
Re: VelocityResponseWriter's future
Posted by Erik Hatcher <er...@gmail.com>.
Oh gosh... there's no "argument" at all. I dig Velocity (and other things), and I'm cool with folks not liking it or not (and you like it, so it seems).
I'm not sure I get what you mean by the testability though. Could you clarify? Taken a bit literally with the VRW, there's this in a test case:
SolrQueryRequest req = req("v.template","custom", "v.template.custom","$response.response.response_data");
//...
rsp.add("response_data", "testing");
vrw.write(buf, req, rsp);
assertEquals("testing", buf.toString());
Pretty predictable in this context, but I think you mean something different than JUnit testing like this.
Regarding documenting comment I made, I was just filling in what I think is needed to making it better and I like your wiki page tutorial idea. But if /browse doesn't work literally out of the box when copying the example configuration files (and as I said in a previous e-mail, neither does Solr Cell, etc) then we don't really have "out-of-the-box"'ness - it requires moving JARs or adjusting solrconfig.xml to make these things work.
Erik
On Dec 9, 2011, at 18:01 , Paul Libbrecht wrote:
> Erik,
>
> don't argue with me about Velocity, I'm using it several hours a day in XWiki.
> It's fast and easy but its testing ability is simply... unpredictable.
>
> I did not mean to say it is not documented enough but that it could be reformulated as a tutorial wiki page instead of an example software.
>
> paul
>
> Le 9 déc. 2011 à 23:17, Erik Hatcher a écrit :
>
>> s/choice templating languages/template language choices/
>>
>> Also, meant to include
>> * http://today.java.net/pub/a/today/2003/12/16/velocity.html
>>
>> On Dec 9, 2011, at 17:07 , Erik Hatcher wrote:
>>
>>> Paul -
>>>
>>> Thanks for your feedback.
>>>
>>> As for JSP... the problem with JSP's is that they must be inside the .war file and that is prohibitive for the flexibility of adjusting the vm files to "create links to the right resource" easily. Certainly choice templating languages are an opinionated kind of thing, and quite obviously I prefer Velocity templating* over pretty much any alternative. Angle brackets are meant for HTML, and mixing JSP and HTML is not very clean to me. And I've built a full-featured browse.jsp and browse.php examples too in past lives too :)
>>>
>>> Regarding it being an example... it's wired into Solr under example/ as-is. Unfortunately, yet understandably, that example gets copied by many to start new projects and then the UI needs adjustments to be in line with different data (as does the schema and solrconfig, but many folks don't adjust those either). Point taken that it certainly could be implemented/documented better though.
>>>
>>> Erik
>>>
>>>
>>> On Dec 9, 2011, at 16:38 , Paul Libbrecht wrote:
>>>
>>>> Erik,
>>>>
>>>> The VelocityResponseWriter has solved a need by me: provide an interface that shows off an amount of the solr capability with queries close to a developer and a UI that you can mail to colleagues.
>>>>
>>>> The out-of-the-box-ness is crucial here.
>>>> Adjust the vm files was also crucial (e.g. to create links to the right resource).
>>>>
>>>> The VelocityResponseWriter also has a big advantage: it is a very tiny code so it is easy to adapt.
>>>>
>>>> How about making it an example or tutorial?
>>>>
>>>> paul
>>>>
>>>> PS: I'll note that I would prefer a "candid" jsp equivalent (I still do) but it was never available (one day I'll make one).
>>>>
>>>>
>>>> Le 9 déc. 2011 à 22:30, Erik Hatcher a écrit :
>>>>
>>>>> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>>>>>
>>>>> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>>>>>
>>>>> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>>>>>
>>>>> I appreciate your candid thoughts on this.
>>>>>
>>>>> Erik
>>>>>
>>>>
>>>
>>
>
Re: VelocityResponseWriter's future
Posted by Paul Libbrecht <pa...@hoplahup.net>.
Erik,
don't argue with me about Velocity, I'm using it several hours a day in XWiki.
It's fast and easy but its testing ability is simply... unpredictable.
I did not mean to say it is not documented enough but that it could be reformulated as a tutorial wiki page instead of an example software.
paul
Le 9 déc. 2011 à 23:17, Erik Hatcher a écrit :
> s/choice templating languages/template language choices/
>
> Also, meant to include
> * http://today.java.net/pub/a/today/2003/12/16/velocity.html
>
> On Dec 9, 2011, at 17:07 , Erik Hatcher wrote:
>
>> Paul -
>>
>> Thanks for your feedback.
>>
>> As for JSP... the problem with JSP's is that they must be inside the .war file and that is prohibitive for the flexibility of adjusting the vm files to "create links to the right resource" easily. Certainly choice templating languages are an opinionated kind of thing, and quite obviously I prefer Velocity templating* over pretty much any alternative. Angle brackets are meant for HTML, and mixing JSP and HTML is not very clean to me. And I've built a full-featured browse.jsp and browse.php examples too in past lives too :)
>>
>> Regarding it being an example... it's wired into Solr under example/ as-is. Unfortunately, yet understandably, that example gets copied by many to start new projects and then the UI needs adjustments to be in line with different data (as does the schema and solrconfig, but many folks don't adjust those either). Point taken that it certainly could be implemented/documented better though.
>>
>> Erik
>>
>>
>> On Dec 9, 2011, at 16:38 , Paul Libbrecht wrote:
>>
>>> Erik,
>>>
>>> The VelocityResponseWriter has solved a need by me: provide an interface that shows off an amount of the solr capability with queries close to a developer and a UI that you can mail to colleagues.
>>>
>>> The out-of-the-box-ness is crucial here.
>>> Adjust the vm files was also crucial (e.g. to create links to the right resource).
>>>
>>> The VelocityResponseWriter also has a big advantage: it is a very tiny code so it is easy to adapt.
>>>
>>> How about making it an example or tutorial?
>>>
>>> paul
>>>
>>> PS: I'll note that I would prefer a "candid" jsp equivalent (I still do) but it was never available (one day I'll make one).
>>>
>>>
>>> Le 9 déc. 2011 à 22:30, Erik Hatcher a écrit :
>>>
>>>> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>>>>
>>>> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>>>>
>>>> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>>>>
>>>> I appreciate your candid thoughts on this.
>>>>
>>>> Erik
>>>>
>>>
>>
>
Re: VelocityResponseWriter's future
Posted by Erik Hatcher <er...@mac.com>.
s/choice templating languages/template language choices/
Also, meant to include
* http://today.java.net/pub/a/today/2003/12/16/velocity.html
On Dec 9, 2011, at 17:07 , Erik Hatcher wrote:
> Paul -
>
> Thanks for your feedback.
>
> As for JSP... the problem with JSP's is that they must be inside the .war file and that is prohibitive for the flexibility of adjusting the vm files to "create links to the right resource" easily. Certainly choice templating languages are an opinionated kind of thing, and quite obviously I prefer Velocity templating* over pretty much any alternative. Angle brackets are meant for HTML, and mixing JSP and HTML is not very clean to me. And I've built a full-featured browse.jsp and browse.php examples too in past lives too :)
>
> Regarding it being an example... it's wired into Solr under example/ as-is. Unfortunately, yet understandably, that example gets copied by many to start new projects and then the UI needs adjustments to be in line with different data (as does the schema and solrconfig, but many folks don't adjust those either). Point taken that it certainly could be implemented/documented better though.
>
> Erik
>
>
> On Dec 9, 2011, at 16:38 , Paul Libbrecht wrote:
>
>> Erik,
>>
>> The VelocityResponseWriter has solved a need by me: provide an interface that shows off an amount of the solr capability with queries close to a developer and a UI that you can mail to colleagues.
>>
>> The out-of-the-box-ness is crucial here.
>> Adjust the vm files was also crucial (e.g. to create links to the right resource).
>>
>> The VelocityResponseWriter also has a big advantage: it is a very tiny code so it is easy to adapt.
>>
>> How about making it an example or tutorial?
>>
>> paul
>>
>> PS: I'll note that I would prefer a "candid" jsp equivalent (I still do) but it was never available (one day I'll make one).
>>
>>
>> Le 9 déc. 2011 à 22:30, Erik Hatcher a écrit :
>>
>>> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>>>
>>> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>>>
>>> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>>>
>>> I appreciate your candid thoughts on this.
>>>
>>> Erik
>>>
>>
>
Re: VelocityResponseWriter's future
Posted by Erik Hatcher <er...@gmail.com>.
Paul -
Thanks for your feedback.
As for JSP... the problem with JSP's is that they must be inside the .war file and that is prohibitive for the flexibility of adjusting the vm files to "create links to the right resource" easily. Certainly choice templating languages are an opinionated kind of thing, and quite obviously I prefer Velocity templating* over pretty much any alternative. Angle brackets are meant for HTML, and mixing JSP and HTML is not very clean to me. And I've built a full-featured browse.jsp and browse.php examples too in past lives too :)
Regarding it being an example... it's wired into Solr under example/ as-is. Unfortunately, yet understandably, that example gets copied by many to start new projects and then the UI needs adjustments to be in line with different data (as does the schema and solrconfig, but many folks don't adjust those either). Point taken that it certainly could be implemented/documented better though.
Erik
On Dec 9, 2011, at 16:38 , Paul Libbrecht wrote:
> Erik,
>
> The VelocityResponseWriter has solved a need by me: provide an interface that shows off an amount of the solr capability with queries close to a developer and a UI that you can mail to colleagues.
>
> The out-of-the-box-ness is crucial here.
> Adjust the vm files was also crucial (e.g. to create links to the right resource).
>
> The VelocityResponseWriter also has a big advantage: it is a very tiny code so it is easy to adapt.
>
> How about making it an example or tutorial?
>
> paul
>
> PS: I'll note that I would prefer a "candid" jsp equivalent (I still do) but it was never available (one day I'll make one).
>
>
> Le 9 déc. 2011 à 22:30, Erik Hatcher a écrit :
>
>> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>>
>> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>>
>> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>>
>> I appreciate your candid thoughts on this.
>>
>> Erik
>>
>
Re: VelocityResponseWriter's future
Posted by Paul Libbrecht <pa...@hoplahup.net>.
Erik,
The VelocityResponseWriter has solved a need by me: provide an interface that shows off an amount of the solr capability with queries close to a developer and a UI that you can mail to colleagues.
The out-of-the-box-ness is crucial here.
Adjust the vm files was also crucial (e.g. to create links to the right resource).
The VelocityResponseWriter also has a big advantage: it is a very tiny code so it is easy to adapt.
How about making it an example or tutorial?
paul
PS: I'll note that I would prefer a "candid" jsp equivalent (I still do) but it was never available (one day I'll make one).
Le 9 déc. 2011 à 22:30, Erik Hatcher a écrit :
> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>
> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>
> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>
> I appreciate your candid thoughts on this.
>
> Erik
>
Re: VelocityResponseWriter's future
Posted by Jan Høydahl <ja...@cominvent.com>.
Hi,
I think a "/browse" type of experience is crucial for newcomers to quickly get familiar with Solr.
Whether it's Velocity based, AJAX based or another technology is less important.
I personally like VRW and frequently use it as the first step in prototyping in a project. I've also contributed patches to fix bugs and make it more usable.
So unless a new and better alternative is in already in place (I love the idea of AJAX-ifying things), I vote for keeping VRW, but lazy loading it not to annoy people copying example/ around.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 9. des. 2011, at 22:30, Erik Hatcher wrote:
> So I thought that Solr having a decent HTML search UI out of the box was a good idea. I still do. But it's been a bit of a pain to maintain (originally it was a contrib module, then core, then folks didn't want it as a core dependency, and now it is back as a contrib), and the UI has accumulated a fair bit of cruft/ugliness as folks have tacked on "the kitchen sink" into it compared to my idealistic generic (not specific to the example data) lean and clean sensibilities.
>
> What should be done? Who actually cares about VRW or the /browse interface? And if you do care, what do you like or dislike about it? And if you really really care, patches welcome! ;)
>
> Perhaps, as I'm starting to feel in general about open source pet projects, add-on's, "monkey patches" to open source software, it should be moved out of Solr's repo altogether and maintained elsewhere (say my personal or Lucid's github).
>
> I appreciate your candid thoughts on this.
>
> Erik
>