Solaritas was never intended to be used for production situations at
all. It's reason for
existing is to provide:
1> a way to show something prettier than the XML (or JSON or....)
responses to Solr
queries for people just getting started.
2> a way to provide a very quick proof-of-concept/prototyping framework for
_internal_ use. You can very rapidly produce reasonable looking
results pages for
your business folks, product managers, etc.
It was never intended to be a customer-facing front end for Solr...
FWIW
Erick
On Wed, May 9, 2012 at 6:39 AM, Marcelo Carvalho Fernandes
<mcf2...@gmail.com> wrote:
> Now that you gave us more info about your project's requirements it's clear
> to me that Solritas should not be used in your project.
>
> ---------------------
> Marcelo Carvalho Fernandes
> On 9 May 2012 04:56, "András Bártházi" <and...@barthazi.hu> wrote:
>
>> Hi,
>>
>> Solritas (Velocity Response Writer) is NOT intended for production use. The
>> > simple reason, apart from that it is not production grade quality, is
>> that
>> > it requires direct access to the Solr instance, as it is simply a
>> response
>> > writer. You MUST use a separate front end layer above Solr and never
>> expose
>> > Solr directly to the world. So you should feel totally comfortable
>> > continuing to use Solr over HTTP from PHP!
>>
>>
>> Thanks for the response, we're agree.
>>
>> Here is our situation, a bit more detailed.
>>
>> I see only one reason to use Solritas:
>>
>> - a Solritas only solution, the architecture is more simple, and a bit
>> faster as Symfony has 50-100 ms overhead
>>
>> But I see a lot for NOT using:
>>
>> - a very basic (and a bit outdated) documentation
>> - it's 3-4 years old technology, but no mention on the net about it -
>> I've found about 3 mentions to use it for prototyping, seems to be nobody
>> using it, nobody has questions about it
>> - have found no public site using it
>> - it's a template engine based solution, it has no framework around it
>> (like Symfony - I miss a lot of features), it's a view - and implementing
>> logic in a view layer is not a best practice (some logic can be
>> implemented
>> using Java code, but it will still belong to the view layer, and
>> practically)
>> - it's a MODEL (a search query)->VIEW solution with almost no
>> controller, Symfony is a full MVC framework
>> - there can be only one search query on a page, and as we have pages
>> with 3 different queries, and these pages are SEO related, it seems to be
>> not possible to solve it with Solritas (using AJAX may be a solution if
>> SEO
>> would not be important)
>> - we have a lot of PHP based logic (just some basic examples: processing
>> URLs, generating titles), some needs database access as well, porting it
>> to
>> Velocity seems to be a huge task if it's possible at all
>> - some parts, like our autosuggest solutions may be ported to Solritas
>> easily, however it may need changing our quite complex client side
>> JavaScript code, and seems to be a less maintainable situation for our
>> programmers have direct access to the PHP code only
>> - we have tasks those need the search engine, but have no frontend at
>> all, like sending emails with search results based on saved queries, and
>> previously sent results (do not send the same results again)
>>
>> I may have not listed all my points, but these may be show my point of
>> view.
>>
>> Bye,
>> Andras
>>
