On 2/23/10 2:49 PM, Thomas Mortagne wrote: > On Tue, Feb 23, 2010 at 14:08, 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. > > For this one the question is: do we want to allow a user to do > whatever he wants and be invisible from statistics point of view. I > still don't think so. Whatever we think about that it's not a minor > change. > >> * 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). > > That's one of the main difference between action solution and > parameter solution: you don't have anything do here with action > solution because statistics module simply don't know about this action > and don't listen to it so it's not the same kind of complexity. With > parameter solution you need to introduce two new API (the parameter > and the context value) that should be taken into account everywhere > where action is just a kind of plugin. > >> * 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. > > The only good point about this one is that we don't introduce anything > new publicly but apart from this i don't like it very much. It does > not cover properly our use case, we don't want to avoid statistics for > an ajax query that would delete an object for example, that's a valid > user action (done using ajax but still a user action). > >> >> WDYT? > > So to summarize IMO the action solution is the safest and easiest > solution for the use cases we currently have which are internal > queries (mostly ajax).
+1 Jerome > >> >> 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
