[xwiki-devs] How to deal with statistics duplications
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) 2/ pretty much the same thing that 1/ but based on a URL parameter 3/ use an additional AJAX request similar to a google analytics call to record statistics 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
On Wed, Nov 18, 2009 at 5:16 PM, Thomas Mortagne <[email protected]> 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) 2/ pretty much the same thing that 1/ but based on a URL parameter 3/ use an additional AJAX request similar to a google analytics call to record statistics
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/
1/ sounds best. Since those calls are most of the times using xpage=plain for AJAX actions it might be nice to have a new action doing what xpage=plain does, WDYT ? JV.
On 11/18/09 7:09 PM, Jean-Vincent Drean wrote:
On Wed, Nov 18, 2009 at 5:16 PM, Thomas Mortagne <[email protected]> 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) 2/ pretty much the same thing that 1/ but based on a URL parameter 3/ use an additional AJAX request similar to a google analytics call to record statistics
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/
1/ sounds best. Since those calls are most of the times using xpage=plain for AJAX actions it might be nice to have a new action doing what xpage=plain does, WDYT ?
Sounds good. Jerome.
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Nov 18, 2009 at 19:09, Jean-Vincent Drean <[email protected]> wrote:
On Wed, Nov 18, 2009 at 5:16 PM, Thomas Mortagne <[email protected]> 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) 2/ pretty much the same thing that 1/ but based on a URL parameter 3/ use an additional AJAX request similar to a google analytics call to record statistics
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/
1/ sounds best. Since those calls are most of the times using xpage=plain for AJAX actions it might be nice to have a new action doing what xpage=plain does, WDYT ?
Yes that's the idea, fixing a bug by introducing a useful feature :)
JV. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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.
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
Vincent Massol 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.
+1 Thanks, Marius
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
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 ? How would you name this parameter ? Also i really don't like that ajax calls use the standard view action 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
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.
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. 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
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
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 ? 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
-- Thomas Mortagne
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... 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
On Mon, Nov 23, 2009 at 10:43, Vincent Massol <[email protected]> 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...
It seems to do several things related to ajax requests (mainly specific manipulations of the http response for different actions, to make it less interactive I guess).
I think I'd prefer a more explicit param.
I'm not sure about that, something more generic sound better to me. The goal is to hide not user actions (i.e. ajax requests) and not to make any user able to easily make himself hidden...
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
On Nov 23, 2009, at 11:01 AM, Thomas Mortagne wrote:
On Mon, Nov 23, 2009 at 10:43, Vincent Massol <[email protected]> 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...
It seems to do several things related to ajax requests (mainly specific manipulations of the http response for different actions, to make it less interactive I guess).
I think I'd prefer a more explicit param.
I'm not sure about that, something more generic sound better to me.
The need to not register stats is a generic need, not related to ajax requests only.
The goal is to hide not user actions (i.e. ajax requests) and not to make any user able to easily make himself hidden...
I don't see a real problem with this. Thanks -Vincent
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
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.
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Nov 24, 2009, at 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.
I think I'd prefer a more explicit param.
Note that when I replied this I had misunderstood what Thomas was saying. I thought he was talking about a "URL" parameter in the request... I have since understood he was talking about the "ajax" parameter. I agree with Sergiu that reusing the ajax param would be a quick fix that we should probably implement. Thanks -Vincent
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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
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. 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
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. 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
On 11/25/2009 10:26 AM, Vincent Massol 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.
This is also a semi-test with false results. What it should say is that normally URLs should sound meaningful, not that query parameters are completely forbidden. And we pass this requirement, but it's not possible to completely eliminate query parameters. Think about the [[NewDocument]] create links, which have the ?parent in them. Also note that URLs with ?ajax in them should not be visible in the HTML code, since that indicates obtrusive javascript, which is bad.
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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...
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
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
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).
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
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
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.... 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. 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
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
On Feb 23, 2010, at 6:38 PM, Thomas Mortagne wrote:
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.
I can easily imagine not wanting to log in the stats, for example, an object modification done by the scheduler plugin (or the watchlist, or lucene plugin, or...) to some page. It's not just client side, it's about any kind of use case that wouldn't want to log something. A doc change will trigger the stats plugin for edit for ex but if we have the logstats=false in the context then the stats code can check whether it should log anything or not. Yes, I know that in this example you could filter by user to exclude the "superadmin" user from logging anything but you might not want to exclude that user all the time, only for specific actions, like scheduler actions. Re client side, the same applies since the goal of XMLRPC/SOAP/REST is to write client applications that interact with xwiki and you may have the same use case as above but executed from a remote app. Imagine for ex a spam prevention app that would remove spam comments using the REST API. BTW, just to be sure, I did agree about having the special view action for now. I just don't think it's generic enough for the longer term. Thanks -Vincent
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
-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. 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
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query. Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
generic need of excluding actions from being logged at the global level then we could have an actions/stats mapping configured somewhere.
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
-- Thomas Mortagne
On Tue, Feb 23, 2010 at 4:59 PM, Thomas Mortagne <[email protected]> wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0
+0.5
* internal: -1 (not related enough to view)
-1
* service: -1 (there is no reason a service would not log the result in stats)
-1
* minorview: +0.5
-0
* subview: +0.5
+0
generic need of excluding actions from being logged at the global level then we could have an actions/stats mapping configured somewhere.
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
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
As thomas said: "it's about sub request that are part of a bigger request and it happen that in this case we don't want to log view because it's the whole group of query is supposed to mean only one view". viewinternal: +0 get: +0 viewpart: +0 Thanks -Vincent
generic need of excluding actions from being logged at the global level then we could have an actions/stats mapping configured somewhere.
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
On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
What about a simple "get"? If you want to retrieve a resource for the sake of having it as a part of a bigger request you can use a non-semantically-bound and generic action. This could work for every resource: comments, images, attachments, etc. If, on the other hand, you want some additional behavior associated to a specific semantics of the action (e.g., logging or increasing the pageviews when it's actually a view) you use a more specific action like "view", "download", etc. (like it's done right now) -Fabio
On Wed, Feb 24, 2010 at 16:35, Fabio Mancinelli <[email protected]> wrote:
On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
What about a simple "get"?
+1 for get
If you want to retrieve a resource for the sake of having it as a part of a bigger request you can use a non-semantically-bound and generic action. This could work for every resource: comments, images, attachments, etc.
If, on the other hand, you want some additional behavior associated to a specific semantics of the action (e.g., logging or increasing the pageviews when it's actually a view) you use a more specific action like "view", "download", etc. (like it's done right now)
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 2/24/10 4:57 PM, Thomas Mortagne wrote:
On Wed, Feb 24, 2010 at 16:35, Fabio Mancinelli <[email protected]> wrote:
On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
What about a simple "get"?
+1 for get
+1
If you want to retrieve a resource for the sake of having it as a part of a bigger request you can use a non-semantically-bound and generic action. This could work for every resource: comments, images, attachments, etc.
If, on the other hand, you want some additional behavior associated to a specific semantics of the action (e.g., logging or increasing the pageviews when it's actually a view) you use a more specific action like "view", "download", etc. (like it's done right now)
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I like get too, +1. JV. On Wed, Feb 24, 2010 at 4:35 PM, Fabio Mancinelli <[email protected]> wrote:
On Feb 23, 2010, at 4:59 PM, Thomas Mortagne wrote:
On Tue, Feb 23, 2010 at 15:38, Jean-Vincent Drean <[email protected]> wrote:
-0 for a parameter for the same reasons as Thomas. +1 for a new action (/plain/ for example). IMHO If we discover a
Not sure about "plain" since the main use case that raised this issue was about the comments content which is html. Unless you don't mean "plain" as "plain/1.0" renderer syntax but i think we should use something because it does not reflect the fact it's an kind of sub/minor query.
Here is a list coming form the previous mails and some more i can think of (feel free to add others): * plain: -1 * viewinternal: +0 * internal: -1 (not related enough to view) * service: -1 (there is no reason a service would not log the result in stats) * minorview: +0.5 * subview: +0.5
What about a simple "get"?
If you want to retrieve a resource for the sake of having it as a part of a bigger request you can use a non-semantically-bound and generic action. This could work for every resource: comments, images, attachments, etc.
If, on the other hand, you want some additional behavior associated to a specific semantics of the action (e.g., logging or increasing the pageviews when it's actually a view) you use a more specific action like "view", "download", etc. (like it's done right now)
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
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
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
On 11/25/2009 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.
I completely agree. In the long run, I also vote for a different action. In the short term, the easiest thing is to check the ajax param.
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On 11/23/2009 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 ?
Sounds good for a quick solution. Minimal changes, no new bugs, but it will still leave some requests unfiltered.
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/
-- Sergiu Dumitriu http://purl.org/net/sergiu/
On Tue, Nov 24, 2009 at 19:01, Sergiu Dumitriu <[email protected]> wrote:
On 11/23/2009 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 ?
Sounds good for a quick solution. Minimal changes, no new bugs, but it will still leave some requests unfiltered.
Sure. New action is better IMO but since we need to do something quickly and some of us did not want action solution this sounds the way to go for now.
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/
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (8)
-
Anca Luca -
Fabio Mancinelli -
Jean-Vincent Drean -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol