recommendations widget API problem
- 7 years ago
VikasB I might be wrong, but
For anonymous users who come directly from a search engine, the words of the search query that brought them to the topic or article are also used in the search query.that is not the case, search engines, especially Google do NOT provide the search query a user entered into the search field to the website they are led to (AFAIK)...but doesn't really matter =)...
the issue with recreating specialised standard Lithium components like this is a well known problem, the only half reasonable way to do so is very ugly but works in general without trying to reinvent the wheel and all (unknown) algorithms Lithium uses internally to put the content of these components together, if you're ready for ugly, read on =D:
The idea is to parse the markup of the default component for whatever we're looking for, usually some form of ID that we can then use to query the API which will return a more flexible object we can build our markup around based on the same data that the standard component uses...this is of course painful for every developer, but Lithium does not leave us other options sometimes...so here you go (read the comments in the code):
<#-- this assumes that you overwrite your default component in studio by creating a component with the same name and add @override at the end, e.g.
recommendations.widget.recommended-content-taplet@override then you have <@delegate /> available below --> <#assign markup> <#-- pull in the standard component, will output the component's markup into our variable "markup" --> <@delegate /> </#assign> <#assign ids = [] /> <#-- initialize empty sequence for later use --> <#-- parse the markup for whatever we're looking for, in this case topic ids (probably?) I currently do not know a community where this widget is displayed so if you know one let me know, otherwise you have to figure out the correct regex yourself, I assume the topic links usually end with something like ...-p/<topicid>#<messageid>--> <#local idmatches = markup?matches("-p\\/(\\d+)") /> <#list idmatches as id> <#-- only add an id once --> <#-- the ?groups build-in contains a sequence with [0] = the whole match and [0+groupn] items with their match, in this case the <topicid> --> <#if !ids?seq_contains(id?groups[1])> <#local ids = ids + [id?groups[1]]/> </#if> </#list> <#-- then get thread/topic objects from all extracted ids with the REST API --> <#assign query = "SELECT * FROM messages WHERE id IN(${ids?join(',')})"?url /> <#assign response = rest("2.0", "/search?q=" + query) /> <#-- and now you can basically do whatever you want with your topic objects, you're completely free to build the fanciest widgets your clients want from the same data source that the standard component uses...have fun =D --> <#if response.status == "success"> <div class="your-custom-widget-wrapper"> <#list response.data.items as topic> <div class="your-custom-widget-item"> <h3>${topic.subject}</h3> </div> </#list> </div> </#if>