[Zope-dev] Re: [Zope-Coders] Unauthorized results in 401, shouldn't it result in 403?
Sidnei da Silva wrote: | | 2. Is the above behaviour pluggable at all? | | Not at all. | | Should it be? Can it be without impacting on performance? I don't think so. I would expect there's only one sane way to do it. I'm not sure I agree, I've read lots of different views on this sort of thing in these two threads, and I think several of them are valid, while remaining inconsistent with each other. To me, that means it should be pluggable... The source of the other thread is that falling back to unauthorized smells wrong, but I can see at least one case where changing this might break existing apps. Yeah, the one Lennart descibes... Basically it monkeypatches RESPONSE.unauthorized() and RESPONSE._unauthorized(). Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Unauthorized results in 401, shouldn't it result in 403?
On 4/21/05, Chris Withers [EMAIL PROTECTED] wrote: Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder? I think it should be, yes. Or, actually the responsibility of the user object. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Zope-Coders] Unauthorized results in 401, shouldn't it result in 403?
Lennart Regebro wrote: On 4/21/05, Chris Withers [EMAIL PROTECTED] wrote: Aha, as does PAS I see. Does this mean RESPONSE.unauthorized should be a responsibility of the user folder? I think it should be, yes. Or, actually the responsibility of the user object. Why the difference? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RAMcache and container vs. context
I never noticed this before today, but apparently RAMCacheManager is sensitive to whether cached items are acquired from the context or from the container. (Zope 2.7.3 but afaict it should behave the same in any recent version). Is that intended behavior or is this a bug? Let's say I have a CMF site at http://foo:8080/TheSite. And a template at /TheSite/portal_skins/custom/template1 which looks in part like like: p tal:content=context/expensive_script.../p Let's say that expensive_script is also in portal_skins/custom and is associated with a RAMCacheManager. Let's say that there are *no* request variables configured for this RAMCacheManager, which would seem to indicate that we consider all calls to expensive_script equivalent regardless of the request. If I visit http://foo:8080/TheSite/page1, which page makes use of this template, and I reload several times, and look at the RAMCacheManager statistics view, I see several hits for /TheSite/expensive_script. Every time I reload, the hit count goes up by one. So far so good. But if I then visit another page, http://foo:8080/TheSite/page2, which uses the same template, I get a miss and the entry count goes up by one. Reloading then gives me a hit, presumably from the new entry. If I browse around the site, the entry count increments for every new page I hit. Remember that I have nothing configured in the REQUEST Variables field. So the script should be the same regardless of the request right? This was puzzling me until, on a hunch, I looked at the calling template and changed it from this: p tal:content=context/expensive_script.../p ...to this: p tal:content=container/expensive_script.../p And presto, I now get only one entry, and every page on the site gives me a hit from that one entry. Is this really intended behavior? It's not obvious to me from the code why this is happening (or why it might be desirable). The cache manager stores and looks up items by their getPhysicalPath(), so I don't see why context vs. container is relevant. If I'd wanted the URL to be relevant, I would have put that in the REQUEST Variables configuration. This could be a performance hit for the unwary ... aside from all the unnecessary misses, we'd be using RAM on the order of N * M * S where N is number of cached items and M is number of pages in the site, and S is average size of return value. We only should be using N * S. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RAMcache and container vs. context
This is due to how Python Scripts compute their cache keys. The
relevant snippet from PythonScript._exec() is:
asgns = self.getBindingAssignments()
name_context = asgns.getAssignedName('name_context', None)
if name_context:
keyset[name_context] = aq_parent(self).getPhysicalPath()
Note that aq_parent() gives you the URL parent, not the container. I
see no way around that as the return value of a script may well depend
on its context.
HTH,
Stefan
On 21. Apr 2005, at 22:26, Paul Winkler wrote:
It's not obvious to me from the code why this is happening
(or why it might be desirable). The cache manager stores and looks
up items by their getPhysicalPath(), so I don't see why context vs.
container is relevant. If I'd wanted the URL to be relevant,
I would have put that in the REQUEST Variables configuration.
--
Software Engineering is Programming when you can't. --E. W. Dijkstra
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RAMcache and container vs. context
On Fri, Apr 22, 2005 at 12:27:18AM +0200, Stefan H. Holek wrote:
This is due to how Python Scripts compute their cache keys. The
relevant snippet from PythonScript._exec() is:
asgns = self.getBindingAssignments()
name_context = asgns.getAssignedName('name_context', None)
if name_context:
keyset[name_context] = aq_parent(self).getPhysicalPath()
Note that aq_parent() gives you the URL parent, not the container. I
see no way around that as the return value of a script may well depend
on its context.
Yes, it may, agreed. Thanks much for pointing out the relevant
code, at least now I understand what's happening.
But I still would like to argue against this behavior:
There *is* an easy alternative, and that's to put one or more
of the many location-related request variables into the
cache manager's configuration.
This has two advantages: it's more explicit, and control
is given to the site admin rather than hardcoding it.
The disadvantages I see to using my current
container workaround are:
* The templates are client code. Having to change potentially
multiple templates just to affect cacheing behavior of one script
violates the Don't Repeat Yourself principle.
* It's too surprising.
When reviewing code, the difference between context and container
brings many things to mind. Cache hit/miss ratio is not one of them.
When I stumbled on the workaround, if I hadn't bothered to
ask here but had merely committed the change to my templates
and moved on, I would have been programming by coincidence
(see The Pragmatic Programmer).
I'll probably remember it now, but it seems like kind of an
obscure guru-level thing for a template author to have to know,
especially if they are not even a developer and only know how to
write some simple TALES expressions.
* It's an implicit implementation detail. The difference in caching
behavior between context and container is AFAIK not documented
anywhere, not even in the source code (unless you argue that
the semantics of the lines you posted above count as documentation).
Anyway, I have no guarantee that future versions of zope
won't silently break it.
* There are other reasons I might be forced to use context.
For example, if my site offers two CMF skins, each of which
provides some scripts with the same names, I might have common
templates that need to acquire the script from the current
skin and thus may not be able to find it via container.
admittedly there are hacky workarounds in such situations,
e.g. have trivial wrapper scripts live near the templates.
For a related annoyance, see:
http://www.zope.org/Collectors/CMF/343
--
Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
