[Zope-dev] ComponentArchitecture thoughts

[Dieter Maurer]

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