ComponentArchitecture thoughts
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. 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. 2. Simplify the security model more, if possible :) I know, it's been done, but it's still not easy. Sincerely, Tim McLaughlin/tmclaugh PS. of course I have no say in this... but ZC - you asked :)
Hi!
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.
Tim, that's a good point. Though I am quite enthusiastic about having a more component-based architecture for Zope, it has to be at a reasonable "cost".
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. 2. Simplify the security model more, if possible :) I know, it's been done, but it's still not easy.
These two issues can be found in various partly overlapping Fishbowl proposals and initiatives. I think that a lot of people are waiting for them. For security, see the latest threads I and Michael Bernstein have started ;-) One of the important points to make is that ZClasses (or a replacement for them) as well as the security model are frequently used by Zope users (or "configurators") , while the new components model will mainly be a benefit for Zope programmers (i.e. people working on extending Zope rather than just using it). So their impact might be much larger ... If I was asked, I'd say the most important things to do in Zope are "better ZClasses" or whatever can replace their functionality and a more robust and better-to handle security. If all this can be done in a component-oriented way, this would be great. ;-) So the component architecture is more like a paradigm that should be used with new projects than a new "Product" or whatever on its own. Joachim BTW: I missed the chat. Will there be a transscript somewhere on zope.org?
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
On 04 Aug 2001 11:48:49 -0700, Michel Pelletier wrote:
Tim McLaughlin wrote:
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.
Michel, Do you (or Jim) see this aspect of the component architecture solving the issues that I'm trying to deal with in my SecurityJihad proposal? Myself, I'm less concerned with 'mushing' the security in one class, than I am with having to jump though various hoops to get what is supposed to be the default behaviour as described in the developer guide. Michael Bernstein. P.S. for those of you who haven't seen it yet, the proposal is at http://dev.zope.org/Wikis/DevSite/Proposals/SecurityJihad , comments welcome.
Michael R. Bernstein wrote:
On 04 Aug 2001 11:48:49 -0700, Michel Pelletier wrote:
Tim McLaughlin wrote:
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.
Michel,
Do you (or Jim) see this aspect of the component architecture solving the issues that I'm trying to deal with in my SecurityJihad proposal?
Your proposal is good but independent of the component architecture IMHO. Shane
Hi!
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).
I agree that ZClasses are harder to learn and use than necessary. And after reading the new developers guide, I think that even now working with Python Products is not too hard. Setting up a simple content object with Python is easy (basically, use SimpleItem and add some properties and management screens). But there are three things that make ZClasses partly more powerful than Python products: a) they are "over-the-web" b) code changes are reflected in the product immediately c) they behave like "prototypes" or "templates" of complex objects; like folders, they can contain arbitrary Zope objects and make them available to all their instances a) and b) are gradually becoming less important. If you combine the refresh capabilities of Zope 2.4 with Stephan Richter's "Product View" product, you can do most of your coding over the web like in ZClasses. Yes, that's all very experimental, but the proof-of-concept is there. c) is much harder to do because in Python products I can either have methods defined in code or copied to/created in the instances, but nothing comparable to the ZClasses' way of putting stuff into a folder.
Re-doing ZClasses or something like them will be much easier following the component model.
Probably ;-)
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.
That's not completely true ;-) I mean you already can factor out parts of a class into support classes. That's why, If I got it right, most of the magic of components is not new code, but just new coding style, yes? Joachim
Joachim Werner wrote:
That's not completely true ;-) I mean you already can factor out parts of a class into support classes. That's why, If I got it right, most of the magic of components is not new code, but just new coding style, yes?
Essentially, although I don't know if you're talking about inheritance or delegation, our model is based on delegation. In addition there will be new component based protocols for controlling traversal, if you want to get that complex. During these stages security checks can be made using the new security api. this is where we can unify the publisher and restricted code views on security if your thing is a component. -Michel
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
Tim McLaughlin wrote:
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.
I'm really glad to hear that you've found them useful. When I started working on them, I had fairly simple but not well thought through goals for them. There was a good deal of scope creep that led, in part to their complexity. At some point, I'd really like to take another look at ZClasses and better define their goals and uses, and, thus, to correct a lot of the shortcomings they have now.
They are definitely limiting for the developer, but I think they play a valuable role in Zope, and something similar should always exist.
And it will.
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?
Yes. Existing Zope objects will continue to work fine.
Or replace it?
It will augment it.
It seems that backward compatibility could easily be maintained by coexistence.
Yup. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
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
Hi, --On Sonntag, 5. August 2001 20:51 +0200 Dieter Maurer <dieter@handshake.de> wrote: ...
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...
It should be more transparent (and documented :)
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?
I see the improvement more in the domain of abstration. The current situation with much too much hardcoded HTML/HTTP behavior is a big hassle imho. I understand one big goal of the components to help in this matter. Hopefully, if the first integrations were made, the API gets fixed and then all the code is removed and reimplemented from scratch. Otherwise we have a full bunch of working drafts like the current zclass system seems to be. Regards Tino
Dieter Maurer wrote:
Michel Pelletier writes:
(snip)
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.
Really, your second bullet got split into two bullets; everthing else is the same. I agree that there is the same "essential" complexity. I think that many would argue that components provide a cleaner separation of the complexity than mix-ins. The component model envisions more decomposition than we have now with mix-ins, for example, separating presentation from application logic. Many people have bemoaned the intermixing of presentation logic and application logic in Zope today. A really big win from the component model is that it will make it possible for people to extent or replace behavior in other peoples content objects *without modifying the source*.
Maybe, when I see how the cooperating objects are associated, set up, configured...
Yup. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (8)
-
Dieter Maurer -
Jim Fulton -
Joachim Werner -
Michael R. Bernstein -
Michel Pelletier -
Shane Hathaway -
Tim McLaughlin -
Tino Wildenhain