when user searches the keyword then we have to display the search results in two different tabs(products and articles) .
Here articles are html content(we are indexing this). To identify the record we have introduced a property(recordType for Articles/Products).
We have indexed the catalog data and articles(html) data successfully using Switch(different record) in endeca pipeline.
we used “Endeca Record Rollup Key(Aggregated)” feature to get the records.
Here we have couple of questions for implementing pagination for both the tabs.
1)will we get the pagination parmeters for both the aggreate records(products and articles).
2)Ex: If user is in Products tab with pagination page of 3(Assume i got 30 product records and need to display 15 per page) and clicks on articles tab will articles holds the initial values or not.
Again if user clicks on Products tab, we have to show the previous visited pagination (if any).
will this can be achievable or not?
Please suggest me on this. Thanks in advance.
Edited by: Kishore Bellamkonda on Oct 9, 2012 5:02 AM
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
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.