On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote: > On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean > <[email protected]> wrote: >> -0 for a parameter for the same reasons as Thomas. >> +1 for a new action (/plain/ for example). IMHO If we discover a > > Not sure about "plain" since the main use case that raised this issue > was about the comments content which is html. Unless you don't mean > "plain" as "plain/1.0" renderer syntax but i think we should use > something because it does not reflect the fact it's an kind of > sub/minor query. > > Here is a list coming form the previous mails and some more i can > think of (feel free to add others): > * plain: -1 > * viewinternal: +0 > * internal: -1 (not related enough to view) > * service: -1 (there is no reason a service would not log the result in stats) > * minorview: +0.5 > * subview: +0.5
As thomas said: "it's about sub request that are part of a bigger request and it happen that in this case we don't want to log view because it's the whole group of query is supposed to mean only one view". viewinternal: +0 get: +0 viewpart: +0 Thanks -Vincent > >> 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
