[Zope-dev] ComponentArchitecture thoughts

[Tim McLaughlin]

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
>