IMO ZClasses should stay
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better, Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Mar 2006, at 16:25, Jim Fulton wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
I think you are completely right, but I don't think there is anyone who wants to do this documentation task (let alone fix ZClasses) because of the high level of disdain among those people who are actively contributing and have enough knowledge to do it. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEJB8LRAx5nvEhZLIRAmSAAJ4nTAENUdKuEb7SDk/P4QpvjYdCawCfXEOT 8uGgZJfIbcRWRuQLNlDDUyM= =lz3V -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24 Mar 2006, at 16:25, Jim Fulton wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
I think you are completely right, but I don't think there is anyone who wants to do this documentation task (let alone fix ZClasses) because of the high level of disdain among those people who are actively contributing and have enough knowledge to do it.
That's a shame. I don't think that this is a hard task, especially if the person who does it realizes that there is a subset of ZClasses that is useful and not that complicated. Everything else (e.g. "product" generation) should be avoided. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 24. März 2006 11:25:53 -0500 Jim Fulton <jim@zope.com> wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses.
I don't think that ZClasses have real use in the current Zope world except for legacy code. Most people with a solid background write filesystem-based code. That's the official recommended and announced way since years. When look at the Plone world then ppl use Archetypes. Newbies starting with Zope 3 write Python code. Through-the-web scripters can write their applications using ZPT, Python scripts etc. 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.
They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
When I proposed the deprecation of ZClasses almost all vote were pro-deprecation votes. Do we need something better? Can't ppl solve their problems with the solutions mentioned above? Your time and our time is very much limited. 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. Andreas ----------------------------------------------------------------------- - Andreas Jung ZOPYX Ltd. & Co KG - - E-mail: info@zopyx.com Web: www.zopyx.com, www.zopyx.de - -----------------------------------------------------------------------
Andreas Jung wrote:
--On 24. März 2006 11:25:53 -0500 Jim Fulton <jim@zope.com> wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses.
I don't think that ZClasses have real use in the current Zope world except for legacy code.
There are lots of people who have good uses for ZClasses for quick one-off projects. I've heard from some of them.
Most people with a solid background write filesystem-based code.
There are lots of people who use Zope who don't fit this definition. I care about these people. :) ...
Through-the-web scripters can write their applications using ZPT, Python scripts etc.
No, they also need to be able to create simple content types.
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. ...
When I proposed the deprecation of ZClasses almost all vote were pro-deprecation votes.
Sorry, I wasn't paying attention and when I got wind of it, I didn't speak up. The discussion about XML export reminded me that I wanted to mention something.
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.
Your time and our time is very much limited.
Yup
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. I can help out with really deep things. 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. That would be a shame, IMO. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 24. März 2006 12:03:42 -0500 Jim Fulton <jim@zope.com> 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.
Through-the-web 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.
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.
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. Andreas ----------------------------------------------------------------------- - Andreas Jung ZOPYX Ltd. & Co KG - - E-mail: info@zopyx.com Web: www.zopyx.com, www.zopyx.de - -----------------------------------------------------------------------
Andreas Jung wrote:
--On 24. März 2006 12:03:42 -0500 Jim Fulton <jim@zope.com> 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.
Through-the-web 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).
Yup.
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.
Yup.
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.
Yup
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 -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
--On 24. März 2006 11:25:53 -0500 Jim Fulton <jim@zope.com> wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
To relax this discussion a bit: the original plan was to deprecate ZClasses to tell that developer that it is using a somewhat unsupport ancient method to develop with Zope. There was no plan to remove ZClasses after two major releases as usually but to have an option to kick same at some point when they should raise major problems (I know you had some work to get ZClasses working again in Zope 2.8)...well, the point is that there is too much scary code around in Zope 2 where only possibly only one person knows about the deepest internals. Andreas
Andreas Jung wrote:
--On 24. März 2006 11:25:53 -0500 Jim Fulton <jim@zope.com> wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
To relax this discussion a bit: the original plan was to deprecate ZClasses to tell that developer that it is using a somewhat unsupport ancient method to develop with Zope. There was no plan to remove ZClasses after two major releases as usually but to have an option to kick same at some point when they should raise major problems
Cool.
(I know you had some work to get ZClasses working again in Zope 2.8)...well, the point is that there is too much scary code around in Zope 2 where only possibly only one person knows about the deepest internals.
That's not unique to Zope 2, or even Zope. :/ Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton wrote at 2006-3-24 11:25 -0500:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
I am very happy to read this... -- Dieter
--On 24. März 2006 21:05:49 +0100 Dieter Maurer <dieter@handshake.de> wrote:
Jim Fulton wrote at 2006-3-24 11:25 -0500:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
I am very happy to read this...
I still have no idea why you are behind ZClasses? I know that you/we have some legacy ZClasses app running but we don't propagate ZClasses as an implementation solution to co-workers. ZClasses will stay for the time being but they should be regarded as a bad solution for new projects. -aj ----------------------------------------------------------------------- - Andreas Jung ZOPYX Ltd. & Co KG - - E-mail: info@zopyx.com Web: www.zopyx.com, www.zopyx.de - -----------------------------------------------------------------------
Andreas Jung wrote at 2006-3-25 08:19 +0100:
...
I am very happy to read this...
I still have no idea why you are behind ZClasses?
It is nice to have an UI supported way to build applications. ZClasses are in many cases easier than Python based product development.
... ZClasses will stay for the time being but they should be regarded as a bad solution for new projects.
Only because the thread is pending to remove them... Otherwise, they are nice for some types of projects. -- Dieter
+1 I have handed systems with a thin ZClass layer on top to semi- developers and they were *easily* able to take it from there. These are people who would never have grokked (and bothered with) disk- based Python development and all the mumbo-jumbo it entails. No other system has anything even remotely like this. People are *blown away* by the power of building objects TTW (define some properties, write a few scripts and templates, done!). Take that RoR, Django, Vignette, Broadvision, ... ;-) Of course ZClasses have their limitations, but I fully agree that this is first and foremost a documentation problem. Stefan On 24. Mär 2006, at 17:25, Jim Fulton wrote:
On the subject of deprecation, for the record, I think removing ZClasses is a mistake. They have legitimate uses. They have major flaws too. It would help if we would more clearly document their limitations and pitfalls, rather than get rid of them, at least until we have something better,
-- Anything that happens, happens. --Douglas Adams
participants (5)
-
Andreas Jung -
Dieter Maurer -
Jens Vagelpohl -
Jim Fulton -
Stefan H. Holek