-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a generic need of excluding actions from being logged at the global level then we could have an actions/stats mapping configured somewhere.
JV. On Tue, Feb 23, 2010 at 2:08 PM, Vincent Massol <[email protected]> wrote: > > On Nov 25, 2009, at 11:25 AM, Thomas Mortagne wrote: > >> On Wed, Nov 25, 2009 at 10:26, Vincent Massol <[email protected]> wrote: >>> >>> On Nov 25, 2009, at 10:15 AM, Jerome Velociter wrote: >>> >>>> On 11/25/09 10:11 AM, Jerome Velociter wrote: >>>>> On 11/24/09 7:07 PM, Sergiu Dumitriu wrote: >>>>>> On 11/23/2009 10:43 AM, Vincent Massol wrote: >>>>>>> >>>>>>> On Nov 23, 2009, at 10:40 AM, Thomas Mortagne wrote: >>>>>>> >>>>>>>> I just found that we have a "ajax" URL parameter already. It's >>>>>>>> put in >>>>>>>> the context in XWikiAction so we could check for it in statistics. >>>>>>>> >>>>>>>> WDYT about reusing it ? >>>>>>> >>>>>>> What is this URL param doing? The name doesn't sound very >>>>>>> explicit to >>>>>>> tell not to log stats... >>>>>> >>>>>> Currently it prevents in some cases returning the full response. For >>>>>> example, the /cancel/ action normally redirects to view, which in >>>>>> turn >>>>>> renders the entire page. An AJAX request just wants to trigger the >>>>>> cancel action, and doesn't care for the response at all. Not going >>>>>> through the rendering engine is a good performance boost. >>>>>> >>>>>> It's not used for every request done through AJAX, since it must be >>>>>> added manually. >>>>> >>>>> 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. >>>> >>>> Read: >>>> >>>> "Using a different action for service like /service/sounds more >>>> natural, >>>> and easier to learn. >>> >>> "service" doesn't mean much IMO but +1 for a different action on the >>> longer run. Note that WCAG complains about URL with query string (for >>> readability reason) so this solves this problem too. >> >> Adding an action is not that difficult if everyone is agree to go the >> action way now... > > Answering again since we need to move on. My current feeling: > > * Using a new action or passing a parameter to identify a query that > shouldn't be logged (through a URL parameter) sounds the same kind of > complexity to me. > * That said I'm +0 for a new view action (I hope there are no other actions > required though) > * I keep maintaining that the need to not log something should be independent > of the action called and thus even if we had a new action we can also add a > URL parameter to prevent stats logging. "logstats=0|1" sounds good to me. We > could easily make the new view action set the parameter. > * Re the question on how the stats code will get access to that parameter, > yes, it could be put in the context (it could be retrieved from the request > URL but it' not a good idea to become dependent on the environment). > * I'd be +0 to reuse the ajax param too although in the longer run I'd prefer > to introduce a "logstats" param since not wanting to log some stats shouldn't > be related to ajax specifically. It's a more general use case. > > WDYT? > > Thanks > -Vincent > >>> Thanks >>> -Vincent >>> >>>> Jerome" >>>> >>>>>> >>>>>>> I think I'd prefer a more explicit param. >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>>> On Thu, Nov 19, 2009 at 12:04, Thomas Mortagne >>>>>>>> <[email protected]> wrote: >>>>>>>>> On Thu, Nov 19, 2009 at 11:36, Vincent Massol<[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Nov 19, 2009, at 11:26 AM, Thomas Mortagne wrote: >>>>>>>>>> >>>>>>>>>>> On Thu, Nov 19, 2009 at 08:50, Vincent Massol<[email protected] >>>>>>>>>>>> >>>>>>>>>>> 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 > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
