jkevan commented on a change in pull request #368:
URL: https://github.com/apache/unomi/pull/368#discussion_r776750331
##########
File path:
rest/src/main/java/org/apache/unomi/rest/endpoints/ContextJsonEndpoint.java
##########
@@ -378,6 +372,26 @@ private Changes handleRequest(ContextRequest
contextRequest, Session session, Pr
Changes changes =
restServiceUtils.handleEvents(contextRequest.getEvents(), session, profile,
request, response, timestamp);
data.setProcessedEvents(changes.getProcessedItems());
+ List<PersonalizationService.PersonalizedContent> filterNodes =
contextRequest.getFilters();
+ if (filterNodes != null) {
+ data.setFilteringResults(new HashMap<>());
+ for (PersonalizationService.PersonalizedContent
personalizedContent : sanitizePersonalizedContentObjects(filterNodes)) {
+ data.getFilteringResults()
+ .put(personalizedContent.getId(),
personalizationService.filter(profile, session, personalizedContent));
+ }
+ }
+
+ List<PersonalizationService.PersonalizationRequest> personalizations =
contextRequest.getPersonalizations();
+ if (personalizations != null) {
+ data.setPersonalizations(new HashMap<>());
+ for (PersonalizationService.PersonalizationRequest personalization
: sanitizePersonalizations(personalizations)) {
+ PersonalizationResult personalizationResult =
personalizationService.personalizeList(profile, session, personalization);
+ changes.setChangeType(changes.getChangeType() |
personalizationResult.getChangeType());
+ data.getPersonalizations()
+ .put(personalization.getId(),
personalizationResult.getContentIds());
+ }
+ }
+
Review comment:
We could consider using event mechanism to resolve the personalizations,
since it can now modify the profile or the session it would make sense.
And we would benefit from the "changes" return by the event evaluation
instead of having to implement a changes handler inside the personalizaton
layer.
We would need:
- a new event: personalizationEvent that contains the perso(s) to be
evaiuated
- a new action: resolve personalizations
- a new rules that listen on this event to resolve the perso
The only blocking point would be getting the result of the perso from this
kind of execution and pass it to the contextResponse as it was done before.
May be we could store this in the event it self and catching those events
here to get the result out of them.
I dont know why, but I think trying to rely the more we can on
rules/events/actions for internal mechanism improve the genericity of unomi
features.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
