Hi devs, On 02/23/2010 04:38 PM, Jean-Vincent Drean wrote: > -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.
I like plain, meaning xpage=plain. I don't think I've seen any ajax call in my experience with xwiki app development using view action without ?xpage=plain (or something else, like a .vm name or something) -- so it would be kindof nice to have. For me, /plain/ would mean xpage=plain, with *no semantic wrt statistics*, but with the possibility of considering that an xpage=plain is not a 'user view' therefore not stored in the stats. so my +1 goes for introducing the /plain/ action and hooking the nostats to it, and refactoring the document footer to use /plain/ instead of /view/ . The only issue I see with this is when you actually need to do: /view/Space/Page?xpage=plain and /edit/Space/Page?xpage=plain and potentially other actions, with the script in Space.Page depending on the $context.action, in which case you won't be able to use /plain/ anymore. Thanks, Anca > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
