Thanks for the feedback.

You'll be able to connect to any solr box in all 3 options. In the first option you'll connect to it directly as it will part of the solr runtime (just like the admin pages). In the second option, you'll still be able to configure different cores but at runtime via a wizard.

Cheers,
Uri

Pradeep Pujari wrote:
Option 3 is very flexible, can be configured to any core like QA box or 
integration box.

Pradeep.


--- On Tue, 4/6/10, Uri Boness (JIRA) <j...@apache.org> wrote:

From: Uri Boness (JIRA) <j...@apache.org>
Subject: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for 
Solr
To: solr-dev@lucene.apache.org
Date: Tuesday, April 6, 2010, 1:19 PM

    [ 
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854155#action_12854155
]
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: https://issues.apache.org/jira/browse/SOLR-1163
   Project: Solr
          Issue Type: New
Feature
          Components: web gui
    Affects Versions: 1.3
            Reporter: Uri
Boness
         Attachments:
graphics.zip, 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: 
http://search.jteam.nl/explorer. 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: http://search.jteam.nl/help
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.



Reply via email to