On 02/24/2010 06:01 PM, Thomas Mortagne wrote: > 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
I don't really care that much about the name, it could be anything from my pov. I don't like viewpart because it means "part" which is not always the case (see below, most of the time it's actually the whole page). I'd also expect to have a standard way to say which part... > 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. i'd say "could have been in the page but made it async for performance" is a bit restrictive. Are we talking about this, or we're talking about the general case of 'service views'? I'm thinking at the situation when we build xwiki applications with forms or other content scripted in pages and brought with ajax (look at the annotations for example, where all the views / edit form / create form is brought async with xpage plain). I wouldn't say that's "part of the page but made async for performance", and still I don't think it should count as a 'view' of the script page we're requesting async. However we could consider that the stats discussion doesn't include script pages (they'd be isolated in a "no stats space"), in which case this situation, I'd say quite frequent (at least I did it in the 2 xwiki applications I've written), is not worth discussing. Happy hacking, Anca > >> >> 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 >> > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
