Michel Pelletier writes:
1. Rewrite ZClasses. This is currently an ominous threat that could break much backwards compatibility. Many ZCers want this to happen too. So let's make it happen now, and break less rather than more.
Some points on this: I may have a biased opinion, but I find ZClasses of limited utility. Yes they're easy, but I think that's just because the Python alternative is too hard (which is what components try to address). They are easy, because they can be done through the Web and can easily integrate all site building object types available for Zope.
I read the components proposal. I am not at all sure that this new model will become easier than the current one. Now, I have to know: * which classes I need to mix in * which magic members, I need to supply: "security", "manage_options", "meta_type", "_properties", ... * which magic functions, I need to call: "InitializeClass" Later, I need to know: * which classes I need to mix in (fewer than now, agreed) * which objects I need to cooperate with maybe, how they are set up, configured * which magic members, I need to supply: "__implements__", ... * .... I am not yet happy. Maybe, when I see how the cooperating objects are associated, set up, configured...
The component model really, really will simplify the developer curve by making learning Zope almost exactly like learing python. You'll start with simple classes and examples, move into more complex things step by step. Currently, just to get one product to work, you either have to mimic or understand a lot of code. I am still in doubt...
2. Simplify the security model more, if possible :) I know, it's been done, but it's still not easy.
On the side, keep in mind that the component model will simplify security for the developer quite a bit. By cleanly separating presentation from application from content, you can assess the security needs for each layer independently. Right now, different methods that you want to protect under different policies are all mushed into one class, which is why you *need* to be very verbose with security now. Decomposing that will let you secure your components in bite sized chunks. Now: security.declareProtected(permission, M1, M2, M3, ...)
Then: security.declareObjectProtected(permission) or somethink like this. Is it really a big improvement? Dieter