> 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?
FederationRunHandler does indeed lack this functionality. It certainly
would be nice to add it in but i suspect there's a some stuff to think
about to make it both useful to use and useful to extend.
The solution today is to add the hitcounts together manually in the jsp
templates.
> 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?
We do have the complexity to deal with this. But complex it is - i'll
explain it best i can by running though some basics but it's really
point (c) that solves it for you. And I am expecting questions as i
don't always explain things the best.....
a) modes/mode/comm...@results-to-return
Each command has the "results-to-return" attribute. If the ratio of
results merged on each page was static then you can assign the
appropriate static values, eg results-to-return="7" and
results-to-return="3".
This attribute is really more about performance and it's really only
differences in magnitudes that matter. It does not dictate how many
results to display nor what the "next" offset will be.
b) views/tab/navigation/navigation/result-paging
In views.xml there's another configuration <result-paging .../>
This defines the ResultPagingNavigationController class that helps
maintain page state and create the "previous page" and "next page" links
with values that are propagated into the datamodel at
${DataModel.navigation.navigations['offset'].results}
(see offsetPager.jsp for usage example).
c) modes/mode/comm...@paging-parameter
But most useful, going back to modes.xml, is the "paging-parameter" for
each command (which in turn connects to the result-paging id and command
attributes).
We did some work in the beginning of 2.18 to make the "offset"
parameter no longer a global parameter but configured to be named per
command allowing there to exist multiple listings with page states on
one request. For example you might want two result listings side by side
so to compare two indexes and for each listing to have its own "prev"
and "next" buttons. But this extends into a federating use-case when
these two (or more) listings are actually merged together.
d) ResultPagingNavigationController & offsetPager.jsp
Looking at offsetPager.jsp the "prev" and "next" links that it
generates will be wrong now as you need to populate the link's URL with
two offset parameters from two different configured result-paging
elements, for example the links need to have something like
"&command1offset=8&command2offset=4", instead of the default
"&offset=10".
e) FederatedResultPagingNavigationController ?
It would definitely be nice with a subclass like
"FederatedResultPagingNavigationController" that worked along side the
FederationRunHandler. But it would also be nice to think and discuss it
through because up until now the result paging navigation, and all the
navigation run handlers, are part of the view domain, eg "what page do
you want to look at?", but mixing it up with federation hints at the
notion of keeping some continuity of federated results within the model
domain.
~mck
--
"The old law about 'an eye for an eye' leaves everybody blind." Martin
Luther King. Jr.
| semb.wever.org | sesat.no | finn.no |
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Kernel-development mailing list [email protected] http://sesat.no/mailman/listinfo/kernel-development
