I guess in synopsis, I also kinda have the opinion of "if it ain't broke, don't fix it." And since I can build Python products and see other people doing it, I imagine them not to be broken... I'll leave that where it is because it's really a subjective position. As far as ZClasses go, they are definitely useful as they are, but I think they could be more functional. As an example of their usefulness, I've had my HTML productions guys (not developers) using them with great success, and they have relatively little understanding of OOD or Python. They are definitely limiting for the developer, but I think they play a valuable role in Zope, and something similar should always exist. Anyway, after the thoughts are assembled, how does ZC imagine that these new Components will fit into the existing architecture. Will they coexist with the OFS package? Or replace it? It seems that backward compatibility could easily be maintained by coexistence. Tim McLaughlin
-----Original Message----- From: michel@localhost.localdomain [mailto:michel@localhost.localdomain]On Behalf Of Michel Pelletier Sent: Saturday, August 04, 2001 2:49 PM To: Tim McLaughlin Cc: zope-dev@zope.org Subject: Re: [Zope-dev] ComponentArchitecture thoughts
Tim McLaughlin wrote:
I listened in on the chat regarding this and although I
think the idea has
merit, I'm not sure that it is vitally important right now. It could too quickly turn into a lot of burned time with nothing to show for it.
That's one of the risks, yes.
Right now, I think that 2 things could flatten the curve for new developers that are more accessible: 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).
If you talk to Jim at length about ZClasses, your brain will begin to leak out of your head somewhere between meta-classes and persistent classes. Even he says ZClasses are *hard*. The component arch is a piece of cake.
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.
Re-doing ZClasses or something like them will be much easier following the component model.
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.
PS. of course I have no say in this... but ZC - you asked :)
Eveyone has a say in this, that's how it works.
-Michel