Mck,
I feel like I must still be missing the knowledge of how the built-in
federation capability works. When using the FederationRunHandler I get
combined ResultLists, but the hit-count, paging, offset, page-size, and
other command-specific data doesn't change to describe the combined
results. Am I just doing something wrong, or do I need to implement
some API on my EndecaSearchCommand class to make this happen, or do I
need to extend the federationrunhandler to not just insert records into
the destination resultList but also update the hitcount and other
parameters? The problem I see with this latter solution is that the
offset for the anything but the first page of results will not be the
same across the federated command elements (all first page offsets are
0, but if first page of combined results has 7 from command 1 and 3 from
command 2 then second page offsets are 8 for command 1 but 4 from
command 2) - so how can these pages be requested appropriately? My
impression is that a single stateless query is passed from UI back to
the sesat searchcommands, which means that all commands receive the same
offset (which then makes the result pages skip results). Help? My
current mode is:
<endeca-command id="endeca1"
mdex-host="localhost"
mdex-port="10000"
search-interface="All"
result-fields="First Name, Last Name"
results-to-return="10"
>
</endeca-command>
<endeca-command id="globalSearch"
mdex-host="localhost"
mdex-port="10001"
search-interface="All"
result-fields="First Name, Last Name"
results-to-return="10"
>
</endeca-command>
<run-handlers>
<federator from="endeca1" to="globalSearch"
blend="SEQUEL" insert-count="10"/>
</run-handlers>
Brian Frutchey
Federal Solutions Architect
M (703) 597-4875
E [email protected]
Endeca
2100 Reston Parkway Ste 101
Reston, VA 20171
www.endeca.com
find / analyze / understand
-----Original Message-----
From: Mck [mailto:[email protected]]
Sent: Wednesday, August 12, 2009 12:09 PM
To: Brian Frutchey
Subject: RE: Sesat startup feedback
> But this has me wondering how one renders federated results - is there
a
> different JSP for that? Each of the command classes is built for a
> specific index, and I assumed that Sesat takes the results from each,
> merges them, de-dups them, etc. and allows the UI to display the
> combined result.
That's right.
There's no separate jsp so to speak. globalSearch.jsp is just a
template, along with most of the templates. (From experience there's
just too much entropy in the jsps to worry about making them anything
more useful than just examples.) Everything in modes.xml and views.xml
is inherited so here it's just a matter of copying globalSearch.jsp into
your own skin, renaming it to what you wish, change the name of the
search command it references, override the <include element that
references the jsp in views.xml in your skin's tab, and design away.
Federation happens with the FederatorRunHandler
(a result handler happens at the end of every command execution,
but a run handler occurs at the end of execution of all
commands)
Also see FederatorRunHandlerConfig. How results are merged is determined
from the Blend inner class.
NB: currently only SEQUEL is implemented! But we're only talking about a
few lines of code, take a peek inside
FederatorRunHandler.handleRunningQuery. And FederatorRunHandler was
written with the intention of subclassing it often for various
application needs!
It may also be useful to use the CopySearchRunHandler first and before
the merging on a copy of the result list so the original list remains as
is.
De-duping would be another RunHandler (you'd have to implement yourself,
but would be very easy). http://sesat.no/howto-develop-a-runhandler.html
The idea is that the UI, the jsp templates, just iterate over a list of
results without needing to know anything about where those results came
from, whether they were federated, etc etc. At sesam we're swapped out
index implementations a number of times without having to change UI
templates.
> Any chance you have a document describing what each of the modes.xml
dtd
> elements actually does?
Every element and attribute in both modes.xml and views.xml comes from a
Configuration bean. These configuration classes are but POJOs and
usually have a Config suffix classname.
For modes.xml SearchModeFactory deserialises the xml into the following
classes:
mode --> SearchMode (no.sesat.search.mode)
run-transformer --> RunTransform (no.sesat.search.run.transform)
command --> CommandConfig (no.sesat.search.mode.config)
query-builder --> QueryBuilderConfig
(no.sesat.search.mode.command.querybuilder)
query-transformer --> QueryTransformerConfig
(no.sesat.search.query.transform)
result-handler --> ResultHandlerConfig
(no.sesat.search.result.handler)
facet --> Facet (or 'Navigator'. no.sesat.search.result)
run-handler --> RunHandler (no.sesat.search.run.handler)
I described the xml to classname lookup to VJ here (bottom half)
http://sesat.no/pipermail/kernel-development/2009-August/000270.html
Each configuration POJO here is intended as the original source of
documentation and when the modes.xsd is generated
( http://sesat.no/search-modes-schema-generator.html )
the apidoc from the classes is imported into the xml schema. But there's
a lot of apidocs to be desired, so just keep posting questions!
It's a similar story for views.xml starting with SearchTabFactory and
the SearchTab configuration POJO.
~mck
--
"Everything you can imagine is real." Pablo Picasso
| semb.wever.org | sesat.no | finn.no |
_______________________________________________
Kernel-development mailing list
[email protected]
http://sesat.no/mailman/listinfo/kernel-development
