Another open letter. :-)
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. 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) 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 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 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.
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
From: "Dieter Maurer" <dieter@handshake.de>
Here are some things that I feel should be introduced into Zope: - Workflow support. (Because everybody needs it) You know DCWorkflow?
Yes. I think it should be moved off CMF and into Zope proper.
- Versioning. (Because it's hard to do as a product) "CVSFolder" is quite near: I see currently two remaining issues:
Doesn't that store Zope objects in CVS? Or have I missed something completely? If it does, it's not what I'm talking about. The Versioning proposal that is in the dogbowl is what I'm talking about. I was just stressing that it is important.
- Internationalization. (Because it's hard to do as a product) ???
What is your question?
- 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).
My point exactly. :-)
I will soon build my first large application with CMF. We will see whether I will agree with you after that....
Good luck!
Lennart Regebro wrote:
From: "Dieter Maurer" <dieter@handshake.de>
Here are some things that I feel should be introduced into Zope: - Workflow support. (Because everybody needs it)
You know DCWorkflow?
Yes. I think it should be moved off CMF and into Zope proper.
I am actually working on such an animal, but I have no idea when/if I will be able to release the code. My request to the powers that be to be able to release my code is moving very slowly. In the meantime you can use it with a minimalist portal_actions/types/workflow triad with a little patch that's currently sitting in the PTK tracker. Number 401, I think. Sorry, no doco yet :-)
I am actually working on such an animal, but I have no idea when/if I will be able to release the code. My request to the powers that be to be able to release my code is moving very slowly.
In the meantime you can use it with a minimalist portal_actions/types/workflow triad with a little patch that's currently sitting in the PTK tracker. Number 401, I think. Sorry, no doco yet :-)
PLEASE, look at OpenFlow (a Zope Product). It is based on years of research and covers all aspects. It works very well too! Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
Stephan Richter wrote:
I am actually working on such an animal, but I have no idea when/if I will be able to release the code. My request to the powers that be to be able to release my code is moving very slowly.
In the meantime you can use it with a minimalist portal_actions/types/workflow triad with a little patch that's currently sitting in the PTK tracker. Number 401, I think. Sorry, no doco yet :-)
PLEASE, look at OpenFlow (a Zope Product). It is based on years of research and covers all aspects. It works very well too!
Well, I did, actually, for at least a little bit. Its concept of "tokens" seems to be geared much more towards RDBMS-backed apps, and in some areas seems needlessly complex, at least for the app I'm working on.
At 10:12 AM 12/3/2001 -0500, you wrote:
Well, I did, actually, for at least a little bit. Its concept of "tokens" seems to be geared much more towards RDBMS-backed apps, and in some areas seems needlessly complex, at least for the app I'm working on.
I don't agree about the RDBMS stuff, but I agree with you about the complexity. However, I think it is so complex due to its generic approach. It would be so much better, if you would try to build a simpler interface on top of it, than implementing everything again. I have actually done that before with Formulator. iuveno was in the process to develop their own HTML Form tool, when Formulator came around and we dropped it all and just wrote a Product that extended Formulator a little bit for our needs. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management
PLEASE, look at OpenFlow (a Zope Product). It is based on years of research and covers all aspects. It works very well too!
Correct me if I'm mistaken, but from what I saw OpenFlow is very low level. You'd need an entire additional layer to attain what DCWorkflow does. Not that it's bad to be low level, mind you, but that missing layer prevents people from using it directly like DCWorkflow. Florent -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 10 http://nuxeo.com mailto:fg@nuxeo.com
On Monday, December 3, 2001, at 10:36 PM, Florent Guillaume wrote:
PLEASE, look at OpenFlow (a Zope Product). It is based on years of research and covers all aspects. It works very well too!
Correct me if I'm mistaken, but from what I saw OpenFlow is very low level. You'd need an entire additional layer to attain what DCWorkflow does.
Not that it's bad to be low level, mind you, but that missing layer prevents people from using it directly like DCWorkflow.
It's not always good to be high-level either. I've written five custom workflows in the past two months, and only one of them in DCWorkflow. There are a lot of complexities in the workflows that I had to design that DCWorkflow didn't handle -- not to mention the fact that the workflows (which is very central to the system that I'm currently developing) are very essential business components and need to be kept under tighter source code control than occasional .zexp checkins can give me. Don't get me wrong - I like DCWorkflow. But it should not be considered the ultimate workflow solution either. Instead, what should be considered the ultimate workflow solution is the CMF's 'portal_workflow' tool and the interface that Workflow objects have to implement. DCWorkflow gives you an object that implements this interface, and that object in turn gives you the ability to define and manage a workflow through the web. But what makes the system so nice is that you can write your own workflow in Python that lives up to that interface. Or you could write a workflow object that could interpret files exported from a visual workflow design tool. The core WorkflowTool does the basic work -- a developer just has to satisfy a documented interface and register their class with the WorkflowTool as another type of Workflow object that can be added to the system. This is what is so compelling to me about the CMF's Workflow Tool - not that I can design a workflow through the web, but that if I design one through the web and run into limitations, I can do it / redo it all in Python. Jeffrey P Shell, jeffrey@cuemedia.com
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 )
On Monday 03 December 2001 10:09, Danny William Adair wrote:
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
Sorry, maybe I _was_ dreaming. Commercial _support_ (contracts) was planned for a PTK 1.0 release. (search zope@zope.org for "commercial and PTK") Sorry bout that, Danny
Danny William Adair wrote: [snip]
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".
Yikes! I need to get a clarification back to Olivier regarding my point on all this. First, the PTK/CMF evolved separately from Zope, which made it move pretty quickly. All along with thought in terms of the PTK/CMF trying out things that the more conservative Zope development wasn't going after. As we started thinking about Zope3 and a component architecture, we took a look at some of the ideas in the CMF and felt they were a valid approach. As such, the CMF could be thought of as a shipping prototype for ideas that will make it into Zope3. It's true that much of the CMF code should disappear if Zope3 does its job. Perhaps around 50% of the Python code, for instance. The remainder is in areas that we had mixed success on anyway -- namely, the CMFDemo portal doesn't really try to be an out-of-the-box finished product. Most of us would be thrilled to see a different "killer app" develop that took the place of this in Zope3. Certainly existing CMF users shouldn't be worried. For instance, we're planning two important customer engagements that are _just_ starting which will be CMF based. We want to work with people doing projects similar to the CMF and get some common ideas/machinery into the component architecture. Regarding the PTK possibly becoming a commercial product...well, some evolutionary paths are dead ends. :^) --Paul
participants (8)
-
Danny William Adair -
Dieter Maurer -
Florent Guillaume -
Jeffrey P Shell -
Lennart Regebro -
Matt Behrens -
Paul Everitt -
Stephan Richter