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 Romita Saha <Ro...@sg.panasonic.com> on 2012/12/03 10:35:33 UTC
How to change Solr UI
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
Posted by Erik Hatcher <er...@gmail.com>.
All of Solr should be considered "behind the firewall", just like a relational database or any other backend system. It's your job to put a privileged front-end on it.
That being said, Solr's "UI" is really two completely different UI's. There's plain ol' /solr which goes to the nice new admin console straightaway in Solr 4.0. It's built up from LoadAdminUiServlet, HTML, CSS, and JavaScript, and Ajaxing back to various Solr request handlers (templating done entirely client-side in JavaScript). And there's /browse which is a Velocity (formerly known as Solritas) thats original goal was to provide an example playground for the various capabilities of using Solr. It's simply a Solr response writer that outputs the response (object) run through a Velocity template to generate some textual output, which is most commonly useful with HTML or snippets of such.
The templates used to render /browse are found in your Solr Home under conf/velocity/ for each core. You can tinker with those templates to your heart's content, adding functionality and so on. I'll paste below a cute example of what can be done easily with wt=velocity for a nice way to view Solr analysis across all field types.
Again, I'll echo what everyone else always says: Solr is pretty wide-open by default, and there are some fiddly pathways into Solr, that have nothing to do with UI just Solr in general, that are available for delete and other possibly undesirable actions. Exposing Solr to an untrusted client is opening the door up to more than read-only access unless you're *really* careful about adjusting some settings. There are other front-ends for Solr available out there, such as VuFind and Blacklight, that are pretty darn full featured and designed to be deployed as front-end accessible search UI's. For example, see <http://searchworks.stanford.edu/?q=solr> (powered by Blacklight).
Erik
in solrconfig.xml:
<!--
RWX: This request handler was added as an HTML/Ajax view of analysis details of text across
all configured field types
-->
<requestHandler name="/analysis/all" class="solr.DumpRequestHandler" >
<lst name="invariants">
<str name="wt">velocity</str>
<str name="v.template">allyzer</str>
</lst>
</requestHandler>
=============================
in conf/velocity/allyzer.vm:
<!--
TODO: Add error handling (like text analysis on a double type gives a 400)
-->
<html>
<head>
<title>Allyzer</title>
<script type="text/javascript" src="#{url_root}/js/lib/jquery-1.7.2.min.js"></script>
<script type="text/javascript">
function analyze(text) {
$('.ft').each(function(index) {
var ft=$(this).attr('id');
$('#'+ft).load('#{url_for_solr}/analysis/field?analysis.fieldtype='+ft+'&analysis.fieldvalue='+encodeURIComponent(text)+
'&wt=velocity&v.template=analysis');
});
}
</script>
</head>
<body>
Text: <input id="text" type="text"/> <button onclick="javascript:analyze($('#text').val())">Submit</button>
#foreach($ftname in $sort.sort($request.core.schema.fieldTypes.keySet()))
<div>
<h3>$ftname</h3>
<div id="$ftname" class="ft"></div>
</div>
#end
</body>
</html>
=============================
in analysis.vm:
<a href="/solr/#/#{core_name}/analysis?analysis.fieldvalue=$esc.url($request.params.get("analysis.fieldvalue"))&analysis.fieldtype=$esc.url($request.params.get("analysis.fieldtype"))&verbose_output=1">details</a>:
## TODO: consider parameterizing the index/query/(multiterm?), show other attributes?
## Get the *last* item in the index array, as these will be the final tokens indexed
#set($index = $response.response.analysis.field_types.get($request.params.get("analysis.fieldtype")).index.size() - 1)
#foreach($token in $response.response.analysis.field_types.get($request.params.get("analysis.fieldtype")).index.getVal($index))
[$token.text]
#end
On Dec 3, 2012, at 04:35 , Romita Saha 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
Posted by Upayavira <uv...@odoko.co.uk>.
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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
> >
> > Kind regards,
> >
> > Hanjoyo
>
Re: How to change Solr UI
Posted by Upayavira <uv...@odoko.co.uk>.
I guess it is important to distinguish between the
VelocityResponseWriter and the /browse request handler. I suspect you
are referring to the latter.
The /browse interface is both useful and problematic. It is useful
because it allows users to interact with their searches and results in a
more intuitive way, doing useful things like viewing parsed queries,
explains results, and various types of searches and faceting. The
problem with it is that it isn't always obvious that it is intended as
an example, rather than as a fully functioning user interface,
particularly as one that a user might extend for their own use. The
/browse request handler lacks both security (you can't prevent folks
wiping your index) and lacks a controller in an MVC sense.
So, I guess my question is, what is /browse for, and how can we make it
more clear that that is its purpose?
And whether the HTML should be generated client or server side - that's
quite a debate. I went with client side rendering merely to follow the
approach used by the existing admin UI, although there is an added
benefit of it not requiring any special config in solrconfig.xml if it
just uses json. I agree that velocity is just a templating language and
is no way at fault. E.g. I remember a really effective use of XSLT to
render RSS direct out of Solr - worked exceptionally well.
Upayavira
On Fri, Dec 14, 2012, at 05:15 PM, Erik Hatcher wrote:
> There's absolutely nothing inherently wrong with using Velocity with lean
> templating to render responses from Solr. It's just a templating
> technology.
>
> What you've done in your patch is replace the (IMO, and perhaps I'm the
> minority here?) clean Velocity template approach with some
> JavaScript/Ajax, in a much more obscure way to comprehend what is going
> on from UI to response rendering.
>
> But, in your tabbed approach (something I've pondered and built
> prototypes of over the years), the HTML could (/should!) be rendered via
> Velocity templates - easy enough and much cleaner than JavaScript
> templating and actually showcases a better best practice as an example
> anyway, that being generating HTML on the server rather than on the
> client necessarily. I'm of course pretty opinionated on these topics,
> perhaps just for old times sake clinging on to what seems like a clean
> way to do stuff. Velocity itself should not get a bad rap here, since
> it's a top notch technology in and of itself.
>
> I don't disagree that the admin UI ad-hoc querying ought to have the
> tabbed approach, so +1 to that.
>
> Maybe I'll get my wish for Xmas this year... loads of quiet computer time
> to roll up my sleeves and tackle some of the many TODOs I have on the
> Velocity response writer, Prism, and so on. There's good stuff there, so
> I'll aim to do lots of polishing to get this stuff more presentable than
> ever.
>
> Erik
>
>
> On Dec 7, 2012, at 19:33 , Upayavira wrote:
>
> > 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. 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
Posted by Erik Hatcher <er...@gmail.com>.
There's absolutely nothing inherently wrong with using Velocity with lean templating to render responses from Solr. It's just a templating technology.
What you've done in your patch is replace the (IMO, and perhaps I'm the minority here?) clean Velocity template approach with some JavaScript/Ajax, in a much more obscure way to comprehend what is going on from UI to response rendering.
But, in your tabbed approach (something I've pondered and built prototypes of over the years), the HTML could (/should!) be rendered via Velocity templates - easy enough and much cleaner than JavaScript templating and actually showcases a better best practice as an example anyway, that being generating HTML on the server rather than on the client necessarily. I'm of course pretty opinionated on these topics, perhaps just for old times sake clinging on to what seems like a clean way to do stuff. Velocity itself should not get a bad rap here, since it's a top notch technology in and of itself.
I don't disagree that the admin UI ad-hoc querying ought to have the tabbed approach, so +1 to that.
Maybe I'll get my wish for Xmas this year... loads of quiet computer time to roll up my sleeves and tackle some of the many TODOs I have on the Velocity response writer, Prism, and so on. There's good stuff there, so I'll aim to do lots of polishing to get this stuff more presentable than ever.
Erik
On Dec 7, 2012, at 19:33 , Upayavira wrote:
> 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. 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
Posted by Upayavira <uv...@odoko.co.uk>.
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. 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
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Erik Hatcher <er...@gmail.com>.
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
Posted by Upayavira <uv...@odoko.co.uk>.
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
Posted by Jack Krupansky <ja...@basetechnology.com>.
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
Posted by Erik Hatcher <er...@gmail.com>.
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
Posted by Jack Krupansky <ja...@basetechnology.com>.
"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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
>
> Kind regards,
>
> Hanjoyo
Re: How to change Solr UI
Posted by Erik Hatcher <er...@gmail.com>.
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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
>
> Kind regards,
>
> Hanjoyo
Re: How to change Solr UI
Posted by Jack Krupansky <ja...@basetechnology.com>.
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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
Kind regards,
Hanjoyo
Re: How to change Solr UI
Posted by Erick Erickson <er...@gmail.com>.
That's only one example, there are others,
stream.body=<delete><id>blah</id></delete>. or
<delete><query>id:*</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 <ih...@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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
>
> Kind regards,
>
> Hanjoyo
>
Re: How to change Solr UI
Posted by Iwan Hanjoyo <ih...@gmail.com>.
>
>
> 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=true&stream.body=<delete><query>*:*</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=true&stream.body=<delete><query>*:*</query></delete>
Kind regards,
Hanjoyo
Re: How to change Solr UI
Posted by Erick Erickson <er...@gmail.com>.
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=true&stream.body=<delete><query>*:*</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 <ih...@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.Saha@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
Posted by Iwan Hanjoyo <ih...@gmail.com>.
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 <Ro...@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
>