* 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
>>>>>>>> <thomas.mortagne(a)xwiki.com> wrote:
>>>>>>>>> On Thu, Nov 19, 2009 at 11:36, Vincent
Massol<vincent(a)massol.net>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Nov 19, 2009, at 11:26 AM, Thomas Mortagne
wrote:
>>>>>>>>>>
>>>>>>>>>>> On Thu, Nov 19, 2009 at 08:50, Vincent
Massol<vincent(a)massol.net
>>>>>>>>>>>>
>>>>>>>>>>> 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
devs(a)xwiki.org