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