Lennart Regebro writes:

... Here are some things that I feel should be introduced into Zope: - Workflow support. (Because everybody needs it) You know DCWorkflow?

- Versioning. (Because it's hard to do as a product) "CVSFolder" is quite near: I see currently two remaining issues:

* Artificial ever changing "id" values in XML exports which makes automatic merging difficult * discontinuity for subfolders with their own "CVS" and restriction to "Folder" rather than arbitrary "ObjectManagers". I may soon address both issues, unless Steve is faster....

- Internationalization. (Because it's hard to do as a product) ???

- Better user management. (Because everybody needs it) Apparently, I do not... I can live with the existing extension products (true, not with the one in the Zope core).

.... I also feel there are things that could be removed. And now I'm gonna say bad things about parts of zope some people probably love, and they will hate me for this, but I'll have to live with that. This is my view only. I have on occasion been known to be completely wrong. :-)

- Don't do any more work on ZClasses, and eventually drop it. To me they do not seem easier to work with than Python, they are messier and not as flexible. I like ZClasses. Simple Web applications can very easily be build...

- I feel that CMF is a failure. It doesn't do what is promised, it's very hard to understand and many parts of it are simply designed so badly and incorrectly that they are practically useless. Drop CMF. Take the good parts and integrate them directly into the Zope base to make Zope a better platform form content management applications, and forget about the rest. I do not think that CMF is the solution to all problems but in general it seems very useful.

I will soon build my first large application with CMF. We will see whether I will agree with you after that.... Dieter

Hello Lennart, On Monday 03 December 2001 05:06, Lennart Regebro wrote:

After the discussion here I'm slowly starting to form a picture in my mind of how to "solve" the "problems".

First some basic facts of life: - Zope corp needs to do what Zope corp thinks it can make money on.

- "We" (that is the Zope community) need to get some features into the base of Zope because: a. It's not effective that we all solve the same problems independantly. b. Some features are hard to do as products.

- It is imperative that there is a single point of control for Zope, ie no branching.

This means Zope corp needs to control what goes into Zope, but the community needs to tell them what should go there, and the community has to help to put it in. To achieve this, we need better community support systems. That is, we need a proper community site, with discussion forums, a merged collector/proposal application with proper threaded discussions and applied workflow for proposal states. The projects that get started also need their protected areas on the site with discussion forums and their own CVS trees.

In all, this would support a better inflow of comments from the community, it would make it easier for community members to see the responses to their input, and it would be easier to start projects with non ZC people involved in programming.

Definitely. And definitely there needs to be more technical "infrastructure" on zope.org to support this way of working. As another result, less people would find it necessary to move their projects to sourceforge. Just imagine sourceforge functionality plus wikis, plus fishbowls, plus collector. I like the fishbowl's standardization of a common workflow, and I would love to see more integration of all the other parts. I believe this could speed up and stabilize Zope development drastically. Sometimes I even find _navigating_ through _what's_there_ hard, and I'm afraid to spend time writing something that someone else may have already written, and which might just be hidden somewhere in the haystacks...

Here are some things that I feel should be introduced into Zope: - Workflow support. (Because everybody needs it) - Versioning. (Because it's hard to do as a product) - Internationalization. (Because it's hard to do as a product) - Better user management. (Because everybody needs it)

- Documentation (Because everybody needs it - at some point of his/her Zope life)

Also, Zope would benefit from the inclusion of several products that improve the products included in Zope. Many people have found some objects lacking in functionality, and added that functionality and put it up on Zope.org. Many of these improved products could easily replace the products that come with Zope today, thereby giving a better "wow" factor to Zope without much effort.

I think I am not the only one that's afraid of straw fires when it comes to Zope's "wow factor". The decision, which patch/product/add-on should make it to the core and which shouldn't, is not easy. This decision has always been made by ZC, and for the time being I found this fair enough, though it seemed to me that they have been clobbered over the head with patches so much that it became just too much work to review every single one in detail (there are _still_, for months now, so many patches to the tree tag, that enhance its functionality exactly the way that - imho - the tree tag was meant to work, and they still haven't made it to the core). It looks as if out of desperation(convenience?) the burden of proof is being put on the patcher. What I would really love would be a regular poll for developers so that ZC can find out what "the community" would like to see move into the core. And not too abstract (I don't want to vote for "Internationalization", I want to vote for either "ZBabel" or "Localizer", we're not in parliament here). Pick 20 patches/products, and let the community decide over the priorities. Let ZC be the final judge, but let the jury pass their decision ("advice") first. You will always have the problem of this or that patch to apply to a very specific problem of yours. That's why you wrote it. Okay, this patch is essential for your site to work properly, but 99% of the other developers don't need it. If this is the case: tough luck. Pray that they run into the same problems some day. But for the time being, I don't see this causal coherence when it comes to "should and if yes then when will this be taken to the core". So who do I blame? Some people were very quick with their decision here... (see last threads on this list)

I also feel there are things that could be removed. And now I'm gonna say bad things about parts of zope some people probably love, and they will hate me for this, but I'll have to live with that. This is my view only. I have on occasion been known to be completely wrong. :-)

- Don't do any more work on ZClasses, and eventually drop it. To me they do not seem easier to work with than Python, they are messier and not as flexible.

Not much has been done on ZClasses in the last months (sorry if this sounds insulting to someone who has actually worked on them ;-)), so I don't think that there has been much time "wasted" here. If you don't like ZClasses, if they don't seem easier to work with than Python: Ignore them. To a lot of people they are a nice introduction to object-oriented programming under Zope, and for simple tasks (like subclassing and adding/overriding one function of a class) they are quite a handy thing to have around the house, imho. I think that a lot of your concerns will dissolve with the upcoming Component Architecture.

- I feel that CMF is a failure. It doesn't do what is promised, it's very hard to understand and many parts of it are simply designed so badly and incorrectly that they are practically useless. Drop CMF. Take the good parts and integrate them directly into the Zope base to make Zope a better platform form content management applications, and forget about the rest.

The CMF can only be a failure if it fails its goals. Well, what are the CMF's goals? Have you seen this interview? http://www.zopera.org/site/Members/odeckmyn/iv_paul_2001 (recently announced on this list) Quote: "Regarding CMF, we expect it to disappear in its current form, ..." Introduced to us as the "Portal Toolkit", later labeled as "probably evolving into a commercial product" (couldn't find it in the archives when I tried a minute ago, but I know I wasn't dreaming when I read it), then renamed to "Content Management Framework" and the out-of-the-box solution for site developers that need membership, skinning, an easy content management interface, and pluggable add-ons, Paul Everitt now calls it "a big prototype for the new architecture". Although I think that this is not how it all started, not even how it meant to be less than a year ago, you see that your concerns are no longer something to worry about. The "good things" will be taken to the Zope core, the rest will remain interesting only for people who actually "implement". Danny

_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )