--On Mittwoch, 6. April 2005 16:06 Uhr -0400 Jonathan Cyr <[EMAIL PROTECTED]> wrote:
Yoohoo,
ZClasses are not an expert technology to use, they are an introduction to Zope... Just because I use a thing, doesn't mean I can support/maintain a thing. I can read the list, and try to help folks with questions that I've experienced... that's the support that can be offered at my skill level.
There are better ways to learn Zope than by using ZClasses. They should no longer
be mentioned e.g. in the Zope Book.
If that's not enough... fine... drop ZClasses, then DTML (you know, its next)... and all the folks in this boat with me.
That's nonsense. Open-source is a giving and taking. Ok, you can demand something
*but* the resources of the people giving something to you are limited and restricted
by several constraints (company needs, personal time etc.). As said a bunch of times
earlier ZClasses help up the 2.8 release. Every software has its life-cycle it is sometimes
a good thing to drop old things over board *if* they tend to cause serious problems.
This is here the case. So my proposal was to deprecate them officially in 2.8 with the
possibility to kick them in 2.10 or later. Read carefully ("possibility"). Means if they
do not hurt in 2.10 or 2.11 then could stay but ZClasses could be removed if major
resources would be necessary to fix them.
ZC should decide whether the benefits of ZClasses for low-end developers match against the hurdles to keeping it with the newer Zope releases. If they don't see a need for this skill-level type of tool in Zope's feature list, they will pay down the road... Growth is king, even for Zope, who grew this platform? Growth means newbies, right? What elements got Zope to where it is? Could ZClasses be on that list? Why?
And seeing comments like...
- "Move to Zope Python Products" - you cant see the skill differences between OOP & Zope's API vs. ZClasses
- "Use the Archetypes/CMF/Plone setup" - UML training? the CMF API and Plone underpinnings, easy?
If you are a somewhat clever (I assume you are) than you should be able
to adopt these technologies with a resonable amout of time. Using AT
as an example is easy and *more* straight forward than using ZClasses
where you can run against the wall very easily. From the programmers experiences
these frameworks are the future and definitely not ZClasses.
- "Maintain it yourself then" - Update very slick code within Zope's flexible and aging API, with ZODB API too? Maintain it...Yeah sure, hows this afternoon.
See above....if you have a need or interest in keep ZClasses you could pay Jim
some USD to fix ZClasses for you. I don't see it as a responsibility to provide
backward-compatibility for all and everything for ages. It would be nice to have
that *but* our resources are limited - they are especially limited because I see
little interest of the community helping out in Zope areas where work must be done.
Means the active people in the Zope community have/try to do help out in many fields
restricting their time from serious Zope work.
-aj
pgp37nCOck6sF.pgp
Description: PGP signature_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
