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

On 11/24/09 7:07 PM, Sergiu Dumitriu wrote: In the long run, I don't like too much this solution, since it forces developers to be aware of that and to add the ajax=1 to all their AJAX requests. Using a different action for service like /service/ Jerome sounds more natural, and easier to learn.

> >> I think I'd prefer a more explicit param. >> >> 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