Re: [xwiki-devs] How to deal with statistics duplications

On Mon, Nov 23, 2009 at 10:43, Vincent Massol <vincent(a)massol.net> wrote: It seems to do several things related to ajax requests (mainly specific manipulations of the http response for different actions, to make it less interactive I guess). I'm not sure about that, something more generic sound better to me.

The goal is to hide not user actions (i.e. ajax requests) and not to make any user able to easily make himself hidden...

> Thanks > -Vincent > >> On Thu, Nov 19, 2009 at 12:04, Thomas Mortagne >> <thomas.mortagne(a)xwiki.com> wrote: >>> On Thu, Nov 19, 2009 at 11:36, Vincent Massol <vincent(a)massol.net> >>> wrote: >>>> >>>> On Nov 19, 2009, at 11:26 AM, Thomas Mortagne wrote: >>>> >>>>> On Thu, Nov 19, 2009 at 08:50, Vincent Massol >>>>> <vincent(a)massol.net> >>>>> wrote: >>>>>> >>>>>> On Nov 18, 2009, at 5:16 PM, Thomas Mortagne wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Since we introduce document footer informations view statistics >>>>>>> are >>>>>>> store several time for the same user view of a page. >>>>>>> >>>>>>> See http://jira.xwiki.org/jira/browse/XWIKI-4590 >>>>>>> >>>>>>> The issue is that theses tabs are loaded asynchronously in ajax >>>>>>> and >>>>>>> make a call using view action. >>>>>>> >>>>>>> Here are some solutions: >>>>>>> 1/ introduce a new action "viewinternal", "service" or anything >>>>>>> else >>>>>>> that would be a "view" action without UI and not taken into >>>>>>> account by >>>>>>> statistics (that register for "view" action events) >>>>>> >>>>>> +0 >>>>>> >>>>>>> 2/ pretty much the same thing that 1/ but based on a URL >>>>>>> parameter >>>>>> >>>>>> +1 >>>>>> >>>>>> This is much better to me since: >>>>>> * Stats are a transersval concern, not related to the view >>>>>> action >>>>>> especially. I'm pretty sure we can imagine use cases where we >>>>>> don't >>>>>> want to register stats for actions other than view >>>>>> * The way I'd like to implement the actions later on (xwiki- >>>>>> actions >>>>>> module) is to have action pipelines and this "saving stats" >>>>>> action >>>>>> will be implemented as a post-action that would be injected >>>>>> after the >>>>>> main actions. Thus only this post action will need to check the >>>>>> parameter which will be transparent to the other actions, thus >>>>>> providing a good separation of concern. >>>>> >>>>> So you want statistics module to go look at URL parameters ? >>>> >>>> I said the opposite actually: it's the action that should do this. >>>> Right now (current code) we could just have the view action check >>>> for >>>> the param. >>> >>> And do what, put something in the context ? The statistics module >>> will >>> still receive a "view" action event. It has to check something. >>> >>>> >>>>> How would >>>>> you name this parameter ? >>>> >>>> Some proposals: >>>> - "stats=true|false" (or 0|1 to follow the current "tradition") >>>> - "logstats" >>>> >>>>> Also i really don't like that ajax calls use the standard view >>>>> action >>>> >>>> Can you explain? I don't see the problem. >>> >>> "view" action is supposed to be a user view of a document, ajax >>> calls >>> are retrieving structured informations from a service located in a >>> page most of the time so they have to explicitly tweak the URL to >>> remove the UI, indicate they want plain renderer... and so get >>> something that has nothing to do with what "view" action is >>> supposed >>> to be. >>> >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> so the "viewinternal" action is needed anyway IMO. >>>>> >>>>>> >>>>>>> 3/ use an additional AJAX request similar to a google analytics >>>>>>> call >>>>>>> to record statistics >>>>>> >>>>>> -1 >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> >>>>>>> As i said in jira I'm against 3/ >>>>>>> >>>>>>> 2/ seems too big for a URL parameter to me and it makes >>>>>>> statistics >>>>>>> depends on URL parameters where 1/ fix the issue without >>>>>>> touching >>>>>>> anything in the statistics module >>>>>>> >>>>>>> +1 for 1/ >>>>>>> +0 for 2/ >>>>>>> -1 for 3/ >>>>>>> >>>>>>> -- >>>>>>> Thomas Mortagne