Andreas Jung wrote:

--On 24. März 2006 12:03:42 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:

There are lots of people who have good uses for ZClasses for
quick one-off projects.  I've heard from some of them.

There are lots of people who use Zope who don't fit this
definition.  I care about these people. :)

I've haven't seen those ppl raising their hand when making the proposal.
I assume they died of ZClasses-disease.

Actually, they've met with ridicule, or so I'm told
and probably didn't think their opinions were welcome.

scripters can write their applications using ZPT, Python scripts etc.

No, they also need to be able to create simple content types.

A somewhat talented developer will succeed in doing filesystem-based
development. The scripters I've seen so far either developed their skills or had other ppl in their team doing a related development.

I know you are aware of the non-developer who built a successful
content-management system that replaced Vignette in a major media
company.  They did this with ZClasses.

Of course, in this case, they eventually hired developers to
reimplement the app in a more scalable and maintainable form.
Still their use of ZClasses was extremely rewarding for them
and later for the developer.

Only ppl with legacy code or ppl unwilling to migrate their apps to a
filesystem-based implementation are still using ZClasses. None of us is
announcing ZClasses as solution to develop wit Zope.

ZClasses are not a good solution for developing products or
complex applications requiring maintenance. They are a
reasonable solution for quick one-off apps.

That's what we are trying to tell to the ppl with the deprecating warning.
ZClasses can be/are a one-way road.

What we should tell them is that they aren't a road at all. :)

Do we need something better? Can't ppl solve their problems with the
solutions mentioned above?

I think we need a good "scripting" story for non developers.  A better
story might look nothing like ZClasses. It might not even be TTW,
but I hate to toss ZClasses until we have something better.

As mentioned in my other mail. We will keep than as long they are maintainable in a reasonable way but we must tell the ppl clearly about the pros and cons (especially the cons).


 > We should spend this time

on useful Zope projects and not in supporting ancient concepts that
don't help the majority of the Zope developers.

If the only things we can support are things that I can work on, we are
in big trouble.

Right but as you know Zope 2.8 was delayed for a long time because you were the only person able or willing to fix the outstanding ZClasses problems.


 I can help out with really deep things.

Of course we appreciate that but having a single person to be able to deal with singularities as ZClasses is always a bottleneck especially since we changed to a timed-based release schedule.

There are

some shallow things that could be done, like writing docs and removing
harmful features, which should be UI work.  You are right, If no one
but me is willing to do any work on them, they should probably go.

'willing' to work on something is possibly the largest problem in the Zope 2
world right now.


> I do also prefer to spend my time on more interesting
projects in the Zope world than digging through ancient, scary code.

We have to be willing to work on old code.  We can't always be
inventing new code.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to