This content has been marked as final. Show 3 replies
My two cents here... As a user, I might find switching tabs and being on the same page of results as the previous tab odd. For example, if I went to page 3 on the Records tab then switched to Articles, I would expect to be on page 1. But that's just me of course. And if you had a situation where the 30 results returned 29 Records and 1 Article, the paging on each tab would be hard to manage and perhaps confusing to your end users.
By the way, the question on whether or not paging parameters work on when you are doing a rollup key on a mix of records that roll up and do not roll up - it will work fine. You can validate that easily enough in the wine reference app.
That said, I don't think you can use the Endeca paging logic if you are splitting the result set and putting some records into one tab and the others in another. Or I'm missing your point.
In addition, your little question has lots of side questions:
Presumably you have other dimensions besides Record and Article. Some of these dimensions may only be applicable to Records or Articles. Would you want to show Article only dimensions when the user is viewing Records?
Also, presumably you would also like to show counts or disable a tab if no results. You could easily get the counts from the RecordType refinement values of Article and Records. If the refinement value doesn't exist, then the count is 0.
I might approach this by performing two queries. One query to get all of the records, navigation, and paging information for the record type of the tab the user is on, and a second query to just get the totalRecordCount (return 0 records) for the other tab. On each of these queries, you would add a record filter. Ie. Nr=AND(RecordType:Article). You would have to be careful here on refinements and not apply Record only refinements to Articles and vice-versa. You'll have to manage this in your application logic I think.
With this approach it should be easy to disable a tab; show tab counts; keep separate paging states per tab; show dimensions specific to a record type...
It would be a cleaner approach with quereis seperately for two type of results (Product and Articles) - you can use a hidden diemsion or filter expression to get only the product or only the articles. By this way you will have control over all the displayable things in a page, likely left nav(dimensions), pagination etc
Create a new property (call it rollup key), map the rollup property of Products and rollup property of Articles to it, so that you can use a single rollup key while querying for aggregated records.
To answer your 2nd query it all depends on how you do your logic at UI layer, Endeca is stateless- may be you need to cache the last visited page in the Products tab, when user comes back to this tab again call to endeca by setting the cache page number, that would do
Edited by: Dev Reddy on Oct 16, 2012 7:00 AM
I agree with Reddy completely. However, there is one more very important reason that you should query the MDEX for products and articles separately. Assuming you have a relevancy strategy employed, the MDEX will sort your results by which records are most relevant. If you're querying the MDEX only once for both products and articles, you might find that the first 20 relevant records are all articles and no products. This will become a problem when you try to display the first page of result for products. The MDEX will "recall" all of the right product records and this will be reflected in guided navigation, but without any product results returned for display you'll have issue making the UI work properly.
Additionally, you should also be defining different search interfaces to search against for your separate product and article search queries. This way, you can specify different relevancy approaches and tune your searching independently for product searches vs. article searches.