On Wed, Feb 24, 2010 at 16:23, Anca Luca <[email protected]> wrote: > 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.
I don't like plain in "plain" in xpage=plain so obviously i don't like it either as the action name. Another thing is that the xpage=plain is about viewing a page (which is why it's generally used with view action) but without the UI which has nothing to do with what we want here. We want to asynchronously get a part of the page that could have been in the page but we decided to make it async for performance reasons. > > 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 > -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
