"Chris McDonough" <chrism@zope.com> wrote:
How do you define a "page"? I consider a "page" the thing rendered when a user visits a URL. Since access rules trigger on any URL visitation, this means you can write a log of "pages" visited via an access rule. But it seems you are defining "page" in a different way; what defines a "page" to you?
Do you want to track all calls to other Zope objects inside a Zope object? This is very difficult and probably not worth it. The logs generated would be huge and would have pointless amounts of detail, most of which you probably wouldn't care about.
Good point--I may have simplified the problem too much. Users see a rendered screen created by rendering a number of Zope and HTML objects. 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. 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. I am only interested in tracking the root object of each of the various possible displayable pages. Had the Site Access approach done the job, I was expecting to filter out much of the information early to keep the size of the log file within bounds and to minimize overheads as much as possible. One approach would be to insert a bit of DTML or python script to do the logging, but there are lots of pages and most are static. I suppose I could make a wrapper for them which does the logging--but I think that's the wrong place to do it. I'm hoping there's a hook which does pretty much the same thing... 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.