lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pradeep Pujari <>
Subject Re: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for Solr
Date Wed, 07 Apr 2010 07:31:09 GMT
Option 3 is very flexible, can be configured to any core like QA box or integration box.


--- On Tue, 4/6/10, Uri Boness (JIRA) <> wrote:

> From: Uri Boness (JIRA) <>
> Subject: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for Solr
> To:
> Date: Tuesday, April 6, 2010, 1:19 PM
>     [
> ] 
> Uri Boness commented on SOLR-1163:
> ----------------------------------
> working on a new improved patch for the explorer. But I'm
> at a bit of a dilemma here regarding exactly it should
> integrate with Solr. There are basically 3 options:
> 1. Tight integration, where the explorer will be bound to
> each core and there will be a dedicated URL for it (say
> /corename/explorer). This is nice as the user gets this
> functionality out of the box, but on the other hand, I'm not
> sure users want it to be there out of the box (most of the
> time, if not always, the explorer will not be used as the
> final UI, but more of a temporary one, just to have
> something up and running... in production I can imagine
> users will not need it). This tight integration also means
> quite a lot of changes to the current configuration, well,
> first the dispatch filter will need to change a bit, but
> also a default request handler will need to be defined for
> all cores.
> 2. The other option is to keep the explorer as an external
> tool. The idea is to have it as a separate war file which
> can be deployed in the same servlet container as solr. I'm
> working on removing the current xml configuration and make
> it more dynamic. So when the user enters the application,
> she can configure a core by following a wizard-like
> process... this wizard will create a configuration which
> will be saved on the server for future "logins". 
> 3. Well, the third option is just to leave things as they
> are now. That is, there is on configuration file which
> defines all the solr cores the explorer can communicate
> with. This configuration file is loaded when the web page is
> loaded. Like option 2, this is also a standalone mode.
> any comments?
> > Solr Explorer - A generic GWT client for Solr
> > ---------------------------------------------
> >
> >             
>    Key: SOLR-1163
> >             
>    URL:
> >         
>    Project: Solr
> >          Issue Type: New
> Feature
> >          Components: web gui
> >    Affects Versions: 1.3
> >            Reporter: Uri
> Boness
> >         Attachments:
>, solr-explorer.patch, solr-explorer.patch
> >
> >
> > The attached patch is a GWT generic client for solr.
> It is currently standalone, meaning that once built, one can
> open the generated HTML file in a browser and communicate
> with any deployed solr. It is configured with it's own
> configuration file, where one can configure the solr
> instance/core to connect to. Since it's currently standalone
> and completely client side based, it uses JSON with padding
> (cross-side scripting) to connect to remote solr servers.
> Some of the supported features:
> > - Simple query search
> > - Sorting - one can dynamically define new sort
> criterias
> > - Search results are rendered very much like Google
> search results are rendered. It is also possible to view all
> stored field values for every hit. 
> > - Custom hit rendering - It is possible to show
> thumbnails (images) per hit and also customize a view for a
> hit based on html templates
> > - Faceting - one can dynamically define field and
> query facets via the UI. it is also possible to
> pre-configure these facets in the configuration file.
> > - Highlighting - you can dynamically configure
> highlighting. it can also be pre-configured in the
> configuration file
> > - Spellchecking - you can dynamically configure spell
> checking. Can also be done in the configuration file.
> Supports collation. It is also possible to send "build" and
> "reload" commands.
> > - Data import handler - if used, it is possible to
> send a "full-import" and "status" command ("delta-import" is
> not implemented yet, but it's easy to add)
> > - Console - For development time, there's a small
> console which can help to better understand what's going on
> behind the scenes. One can use it to:
> > ** view the client logs
> > ** browse the solr scheme
> > ** View a break down of the current search context
> > ** View a break down of the query URL that is sent to
> solr
> > ** View the raw JSON response returning from Solr
> > This client is actually a platform that can be greatly
> extended for more things. The goal is to have a client where
> the explorer part is just one view of it. Other future views
> include: Monitoring, Administration, Query Builder,
> DataImportHandler configuration, and more...
> > To get a better view of what's currently possible.
> We've set up a public version of this client at: This
client is
> configured with one solr instance where crawled YouTube
> movies where indexed. You can also check out a screencast
> for this deployed client:
> > The patch created a new folder in the contrib.
> directory. Since the patch doesn't contain binaries, an
> additional zip file is provides that needs to be extract to
> add all the required graphics. This module is maven2 based
> and is configured in such a way that all GWT related
> tools/libraries are automatically downloaded when the
> modules is compiled. One of the artifacts of the build is a
> war file which can be deployed in any servlet container.
> > NOTE: this client works best on WebKit based browsers
> (for performance reason) but also works on firefox and ie
> 7+. That said, it should be taken into account that it is
> still under development.
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue
> online.

View raw message