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.
