[Zope-dev] ZPatterns: missing docstring in getItem()

[Phillip J. Eby]

At 08:50 AM 7/13/00 +0100, Steve Alexander wrote:
>"Phillip J. Eby" wrote:
>> 
>> Changes checked in.  I should be releasing an alpha5 tomorrow.
>
>That's great. Did you get my message about errors in triggered methods?

Yes, I did, but the solution requires some more thought.  I had thought I
had the "Transactional" machinery set up so that stuff was only called
during transaction phases where it was safe to throw errors.  So I'm going
to have to go back and review that.  However, I also think that errors in
triggers should result in a rollback-and-abort, rather than silently
failing, which could cause many other problems.

>I realised that I only sent it to the zope-dev list, and not cc-ed to
>you.

Not necessary; my reading rate simply varies.  :)


>> I had hoped to finish my work on proxy roles, ZClass plugins, 
>
>Does that increase the number of "Waaa!" comments in the code?

No, I hadn't even got that far yet.  :)


>> and maybe even my local-roles stuff first and make it a "beta" release, 
>
>*If* you get time, can you put a note on the ZPatterns Wiki, or to the
>zope-dev mailing list briefly describing what proxy roles, and local
>roles mean in the context of ZPatterns? Thanks.

The proxy roles stuff is for Generic providers and triggers, so that when
they execute your expressions they can have roles other than those of the
current user, which is important for constructing secure applications.  The
local roles stuff is the ability to have a DataSkin get local role
information from "local role providers", thus allowing rules-based local
roles to exist/co-exist with the standard Zope persistently-managed local
roles.

One aspect that will be considered in the local roles work is adjusting the
LoginUser class so that it can use more efficient ways of checking access
to an object if it's a DataSkin.  The built-in Zope approach has to look
for *all* local roles that a user has, even when it only wants to know
about one of them.  In general I'd like to see Zope's local role API's
tightened up in this fashion.  Another tightening would be to use the user
object rather than the user's ID or name when calling local-roles API's,
since a rule-based approach may need to consult data on the user object.