[z3-five] Todo list discussion

[Martijn Faassen]

Hey,

Philipp just checked in a todo list:

- make five:viewable support being called several times

- allow Zope2 boilerplate context.registerClass be configured thru zcml

- implement/register missing zope.app directives:

   * browser:defaultView (need extra machinery in Viewable)

   * ...

- support existing __bobo_traverse__ methods

No argument with any of these; these all sound good. The boilerplate one 
sounds like the most involved project.

We should also partition these by 'release'. For 0.1, the upcoming 
release (hopefully later this week, I think we should be doing):

- make five:viewable support being called several times

- support existing __bobo_traverse__methods.

These should be fairly easy to implement. We'll do the other stuff later.

Now on to the points which I have more to say:

secure page templates
=====================

What does this mean? Page templates which fail if they call a method 
that is protected? There was actually a lament on the Zope mailing list 
that this is wrong (Zope 2 does this, but python methods don't have this):

http://mail.zope.org/pipermail/zope-dev/2004-March/022094.html

And a post by Shane Hathaway on it:

http://mail.zope.org/pipermail/zope-dev/2004-March/022104.html

In particular:

"""
Jamie Heilman wrote:
 > Paradoxically, by ignoring Zope's security framework in the context of
 > on-disk methods this actually improves Zope's overall security.

I can see that.  It's interesting that when security is burdensome, it
is often less secure overall as a result.  I see this pattern everywhere.
"""

In this thread I argued it should be an option to have the checks turned 
on, but I've become less convinced as time passes. The only thing such 
checks do is catch bugs in your code; if your page template is somehow 
dependent on user permissions, there always is an explicit check hiding 
out in your code anyway.

There's also a whole new Zope product, TrustedExecutables, which claims:

"As Zope's security checks are expensive, avoiding them can
drastically speed things up."

So, while I wouldn't be against optionally turning this on (perhaps 
during development mode), I'd suggest we actually already have the right 
system right now. :)

now that we have zope:content, do we still need five:implements?
=================================================================

I don't know either. The nice thing about five:implements that is it 
short and to the point. zope:content is a bit more involved (you can 
also do security related stuff) and implies you only do this for content 
classes (even though it works for anything). There's also zope:class 
which does the same but can be used with everything.

In any case, five:implements doesn't do a lot of harm; perhaps we can 
introduce a zope:implements into Zope 3? :)

Regards,

Martijn