Rick - fair enough, indeed. However, for a “static” resource, no Velocity syntax or learning curve needed. In fact, correcting myself, VelocityResponseWriter isn’t even part of the picture for serving a static resource.
Have a look at example/files - https://github.com/apache/lucene-solr/tree/master/solr/example/files The <head> of each page (from head.vm) pulls a “static” resource like this: <script type="text/javascript" src="#{url_for_solr}/admin/file?file=/velocity/js/jquery.tx3-tag-cloud.js&contentType=text/javascript"></script> The /admin/file handler will serve the bytes of any resource in config. As for separate front-end app - always recommended by me, to be sure for real(!) applications, but for internal, one-off, quick and dirty, prototyping, showing off, or handy utility kinda things I’m not opposed to doing the Simplest Possible Thing That Works. As for security - VelocityResponseWriter doesn’t itself add any additional security concerns to Solr - it just transforms the Solr response into some textual (often HTML) format, instead of JSON or XML - so it itself isn’t a security concern. What you need to do for Solr proper for security is a different story, but that is irrelevant to whether wt=velocity is in the mix. It can actually be handy to use wt=velocity from inside a real app - it has been used it for generating e-mails in production systems and simply returning something formatted textually the way you want without an app template tier having to do so. And Velocity, true to name, ain’t slow. For more on /browse, VrW, and example/files usage of those, check out https://lucidworks.com/2015/12/08/browse-new-improved-solr-5/ Erik > On Jan 5, 2018, at 4:19 AM, Rick Leir <rl...@leirtech.com> wrote: > > Using Velocity, you can have some results-driven HTML served by Solr and all > your JS, CSS etc 'assets' served by Apache from /var/www/html. Warning: the > Velocity learning curve is steep and you still need a separate front-end web > app for security because Velocity is a templating output filter. Eric, please > correct me! > > cheers -- Rick > > > On 01/04/2018 11:45 AM, Erik Hatcher wrote: >> All judgements aside on whether this is a preferred way to go, have a look >> at /browse and the VelocityResponseWriter (wt=velocity). It can serve >> static resources. >> >> I’ve built several prototypes this way that have been effective and business >> generating. >> >> Erik >> >>> On Jan 4, 2018, at 11:19, Matthias Geiger <matzschman...@gmail.com> wrote: >>> >>> Hello, >>> i have a web application that delivers static html content to the user. >>> >>> I have been thinking about the possibility to deliver this content from >>> solr instead of delivering it from the filesystem. >>> This would prevent the "double" stored content (html files on file >>> systems + additional solr cores) >>> >>> Is this a viable approach or a no go? >>> In case of a no go why do you think it is wrong >>> >>> In case of the suggestion of a nosql database, what makes noSql superior to >>> solr? >>> >>> Regards and Thanks for your time >
