On May 29, 8:10 am, Wim <[email protected]> wrote:
> Hi,
>
> every tiddler has a "changecount"-parameter.
> Is it possible / easy to add a "viewcount"-parameter that counts... the
> visits of this tiddler?
>
> I know Eric's VisitCount-plugin (http://www.tiddlytools.com/#VisitCounter),
> but this uses browser cookies to store the data.
> In my office, the cookies are removed each night by the IT-department AND I
> want to count the visits (by me and by other collegeas) of tiddlers.
>
> Therefore, a "simple (??) viewcount parameter, identically to the
> changecount-parameter could be a solution.
It would be relatively easy to write a plugin that defines a
'viewcount' macro that increments a custom field named 'viewcount'
whenever it is rendered. This macro could then be embedded in
individual tiddler content (e.g., <<viewcount ...>>) or by added to
the ViewTemplate (e.g., <span macro='viewcount ...'></span>) so that
every tiddler is automatically counted.
However...
The problem with this approach is that every time a tiddler is
*viewed*, it will also be *modified*, and the entire TW document must
then be *saved* order for the incremented viewcount values to persist
between sessions. For the 'changecount' use-case, this isn't a
problem since, by definition, changecount is only incremented if an
actual modification of the tiddler has occurred.
To make a <<viewcount>> macro practical, you really need to use some
kind of storage that is *not* part of the TW document itself, so that
simply viewing a document doesn't automatically modify it. This is
why VisitCounter uses browser-based cookies. It allows the counter
values to persist between sessions, without altering the document
itself.
Unfortunately, as you noted, your office IT department clears all
cookies each night. In addition, even if you could you cookies to
record your own tiddler viewcounts, it would still not achieve the
results you want, which is to record combined viewcounts for *all*
people who view a given tiddler. This clearly indicates a need for
*shared* server-based view counting system.
You could look into using a 3rd-party 'hit counter' service that
supports tracking of individual pages by using arbitrary 'page IDs'.
Then, you could embed their tracking 'bug' into each tiddler, and use
the tiddler title as a page ID. Of course, given your IT department's
cookie-killing paranoia, they probably keep a tight lock on the
company firewall as well, so it's unlikely that they would approve of
any scheme that relies on 3rd-party tracking of activities.
Perhaps you could implement an internal server-based approach that
provides a similar mechanism as the 3rd-party hit counter services;
i.e., a script running on your company's internal web server, invoked
via embedded tracking 'bugs' in the tiddlers, that counts views based
on IDs and stores the counter values on the server.
It just occurred to me... you don't necessarily even need special
server-side scripting to count the tiddler hits. You could embed an
'image bug' into your tiddlers that references a server-side image
file, using the name of the tiddler as part of the name of the image
file. By default, the server should log all requests for files, so
you can use conventional logfile analyzers to generate a report of all
tiddler views, based on a specific server-side path.
For example, you might put something like this into the ViewTemplate
to add an 'image bug' to all tiddlers:
<span macro='tiddler ViewTemplate##tracker with: {{tiddler.title}}'></
span>
<!--
!tracker
<html><nowiki><img src="http://internal.mycompany.com/tiddlertracks/
$1" /></html>
!end
-->
Every time a tiddler is rendered, it will trigger a request for a URL
of the form:
http://internal.mycompany.com/tiddlertracks/NameOfTiddler
which will automatically add an entry in the server-side "httpd.log"
file that tracks all requests for files.
Note that the server-side files (or even the 'tiddlertracks' folder)
do not need to actually exist on the server in order to be counted.
By default, the server should record a '404 error' for all attempts to
access 'missing' files. Thus, you can simply analyze the server's
"error.log" for relevant 404 errors, rather than the analyzing the
full "httpd.log" which tracks all server-side requests. As long as
your IT department doesn't mind the extra web traffic (which is
minimal, as it is just requests, without actual transfer of file
content), this scheme might be your best approach.
Hope this helps,
enjoy,
-e
Eric Shulman
TiddlyTools / ELS Design Studios
----
WAS THIS ANSWER USEFUL? IF SO, PLEASE MAKE A DONATION
http://www.TiddlyTools.com/#Donations
Professional TiddlyWiki Consulting Services...
Analysis, Design, and Custom Solutions:
http://www.TiddlyTools.com/#Contact
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
