[Zope] Re: Access Rules

[Chris McDonough]

> LLL HHHHHHHHH
> aaa bbbbbbbbb
> nnn ZZZZZZZZZ   <= user screen
> nnn ZZZZZZZZZ
> nnn ZZZZZZZZZ
>
> The space indicated by the Z's is the one of interest.  It's the
user's
> workspace and most content is displayed there.  It's usually a
single Zope
> object (with possible sub objects) or a HTML page served from the
local
> file system.  The screen itself is implemented using frames not
tables.
> Naviation happens through a variety of different mechanism
including
> client-side JavaScript to move from one content frame to another.

If so, each access to an object displayed in ZZZ is a separate
request and can be tracked by URL.

> Suppose I have three objects, A, B, and C each of which can be
displayed
> in the Z area.   However it happens via the naviagation, I want to
log
> the time Z displays objects A, B, and C--
>
> sally A t0 t1
> sally B t1 t2
> sally C t2 t3
> sally A t3 t4
>
> and so forth where t0... are times and the navigation moves
amongst the
> various objects with no intermediate steps.

You actually probably don't want to log this information (it's not
efficient to do so).  Instead, you want to log something like the
below:

ref user   page timestamp
1   sally  A    1
2   sally  B    5
3   sally  C    7
4   sally  D    12

(really just the z2.log would do here save for needing to compute
the timestamp from the rendered date)

Then post-process the file to obtain the difference in times between
page-switches to generate the following log:

user    page    time-spent
sally   A       4           # diff between 1 & 2
sally   B       2           # diff between 2 & 3
sally   C       5           # diff between 3 & 4

> BTW, I think it is necessary to track calls to other Zope objects
at
> some level.   Using the example above, when object A gets rendered
you
> get a 'user sally sees object A at time t0' event.  Later another
object
> gets rendered (in the example, object B) which generates two
events:
> 'user sally no longer sees object A at time t1' and 'user sally
sees
> object B at time t1'.  The logging process is complicated because
> rendering object A may reference sub-objects (including object B,
say)
> and may reference objects that are not part of the set of objects
> being logged.  The latter case closes has to be handled to
determine
> the user is no longer viewing to currently open object.

The first problem you have is that you're trying to compute the time
differences between page switches in realtime.  Don't do that.  Log
the simple stuff first and postprocess it to get the more
complicated stuff.

Furthermore, I think the second problem you have is one of
filtering.  There are some URL accesses that you don't care about
(like accesses to the "chrome" and images that make up the UI) and
that's OK.  Just give the objects that you *do* care about a "file
extension" something like "_html".  So each thing you want to render
in ZZZZ, call it "page1_html", "page2_html", etc.  Log every page
access using a URL.  Then filter the log based on your file
extension before postprocessing.

HTH,

- C