On Tue, Feb 23, 2010 at 16:54, Vincent Massol <[email protected]> wrote: > > On Feb 23, 2010, at 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. > > The same can be said of the action.... Instead of using view you'd use > viewinternal or whatever the name and not get the stats logged....
No it's not the same, it only apply to view where your proposal apply to anything. > > And it's not one action that needs to be added but as many as there are > existing actions in order to be complete since we could not want to have > stats logged for the edit action too, save action, preview action, etc. As i said we don't have any use case for something else that internal view queries. I really don't see why we would want to hide a modification from client side. > > Thanks > -Vincent > >>> * 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). >> >>> >>> 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
