i want to develop the tracking tool for campsite. here is just a short
impression:
i am thinking about phpopentracker. in the discussion in semtember john
mentioned problems with performance of this tool. i think, one solution
could be, not to make a database connection, but to write the statements in
a text file and intalling a cronjob, which imports the statements in a
separate database each night and renders reports with special editable
views. so we need not make realtime queries and because of the exported
reports, we could clear old entries.
do you think, this could work?
my favourite way is to implement a counting gif to get the parameters. what
parameters need to be tracked to identify one site clearly? what about the
session und user management? we need a central element, which can render the
counting gif on every site. i think, it is not a good idea, to make this in
the templates. if somebody forgets the counting gif we get lossy datas. is
there any element which is included by every campsite-site?
thank you for ideas.
best flo
------------------------------------------
Posted to Phorum via PhorumMail
>my favourite way is to implement a counting gif to get the parameters. what
>parameters need to be tracked to identify one site clearly?
the main issue is, why i also favour the invisible gif at the moment: there
is no coherent way at the moment by which campsite knows if it displays a
section or an article. these parameters need to be assigned by the webadmin
and could be included in the templates.
>what about the
>session und user management?
this is currently changing as i think the PHP implementation will bring
this up again. don't know. mugur? paul?
>we need a central element, which can render the
>counting gif on every site. i think, it is not a good idea, to make this in
>the templates. if somebody forgets the counting gif we get lossy datas. is
>there any element which is included by every campsite-site?
for the time being, i would like to see a capsule that passes on the
parameters to the log classes. these parameters could come from anywhere.
to start with they come from the gif in the templates. very soon, they come
from the smarty templates? from an extension to the smarty class?
my questions to mugur and paul at this stage would be: if we use caching,
does that still call the class? or will it deliver plain HMTL?
another consideration: the more we move the logging into the campsite
admin, the more we need to think about the specification of 'section
variables' similar to the way they are used in the banner management
software that ondra showed us. forgot the name.
what i mean: at a later stage, the admin will go into the admin of campsite
and activate the log analyser, tell the log analyser wome framework data,
i.e. count all requests with this and this and this template as articles.
count all requrest with this and this template as section, this one as
archive ... and so on.
this is for later. i think. but because that is needed the way campsite
works, i favour the gif thing for now and the idea that for starters, the
parameters are passed on from the template and set by the admin inside the
template. later, these parameters can come from a smarty extension, or
something else.
content and media development http://mi.cz
----------------------------------------------------------------- http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
"Und damit bin ich immer noch billiger als ein Fachlabor."
(Ole Broemme)
-----------------------------------------------------------------
------------------------------------------
Posted to Phorum via PhorumMail
>my favourite way is to implement a counting gif to get the parameters.
what
>parameters need to be tracked to identify one site clearly?
the main issue is, why i also favour the invisible gif at the moment: there
is no coherent way at the moment by which campsite knows if it displays a
section or an article. these parameters need to be assigned by the webadmin
and could be included in the templates.
>what about the
>session und user management?
this is currently changing as i think the PHP implementation will bring
this up again. don't know. mugur? paul?
>we need a central element, which can render the
>counting gif on every site. i think, it is not a good idea, to make this
in
>the templates. if somebody forgets the counting gif we get lossy datas. is
>there any element which is included by every campsite-site?
for the time being, i would like to see a capsule that passes on the
parameters to the log classes. these parameters could come from anywhere.
to start with they come from the gif in the templates. very soon, they come
from the smarty templates? from an extension to the smarty class?
my questions to mugur and paul at this stage would be: if we use caching,
does that still call the class? or will it deliver plain HMTL?
another consideration: the more we move the logging into the campsite
admin, the more we need to think about the specification of 'section
variables' similar to the way they are used in the banner management
software that ondra showed us. forgot the name.
what i mean: at a later stage, the admin will go into the admin of campsite
and activate the log analyser, tell the log analyser wome framework data,
i.e. count all requests with this and this and this template as articles.
count all requrest with this and this template as section, this one as
archive ... and so on.
this is for later. i think. but because that is needed the way campsite
works, i favour the gif thing for now and the idea that for starters, the
parameters are passed on from the template and set by the admin inside the
template. later, these parameters can come from a smarty extension, or
something else.
content and media development http://mi.cz
----------------------------------------------------------------- http://www.campware.org -- http://crash.mi.cz -- http://sue.mi.cz
"Und damit bin ich immer noch billiger als ein Fachlabor."
(Ole Broemme)
-----------------------------------------------------------------
------------------------------------------
Posted to Phorum via PhorumMail
> i think, one solution
> could be, not to make a database connection, but to write the statements in
> a text file and intalling a cronjob, which imports the statements in a
> separate database each night and renders reports with special editable
> views. so we need not make realtime queries and because of the exported
> reports, we could clear old entries. do you think, this could work?
Sure and I think this solution is better than the next one. We did some
analysis on this issue at the summer camp but unfortunatelly I don't know where
did I put those documents. Maybe Paul has them... Paul, can you help?
> my favourite way is to implement a counting gif to get the parameters. what
> parameters need to be tracked to identify one site clearly? what about the
> session und user management? we need a central element, which can render the
> counting gif on every site. i think, it is not a good idea, to make this in
> the templates. if somebody forgets the counting gif we get lossy datas. is
> there any element which is included by every campsite-site?
Nope, you have to insert the gif link manually in every main template.
Mugur
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com
------------------------------------------
Posted to Phorum via PhorumMail