Tres Seaver wrote:
I'm OK with having in-tree code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that janitorial deprecation is way too common in the tree today:
people decide they don't like the name a method was given, and
Christian Theune wrote:
Why? Because we keep changing stuff and don't tell people in VERY LARGE
LETTERS about it.
Actually, you highlighted the wrong bit, the important bit is:
BECAUSE WE KEEP CHANGING STUFF
Using Zope 3, and Zope 2 since the Zope 3 stuff started getting merged
in is like
Christian Theune wrote:
this is a rant. I don't want to be destructive or disruptive, but I feel
like I need to turn this up right now.
Let's start with something positive: I love Zope 3. I do. I know it
almost since the beginning and I see how it works out.
But to be honest, I too often get
Martijn Faassen wrote:
So, my proposal for Zope 3.4:
* have a developer_notes file or directory somewhere.
* let this contain the developer-visible changes.
* it should be focused on how to change your code. That's the important
bit. Motivations and such might also be useful to
Dieter Maurer wrote:
Tres Seaver wrote at 2006-9-2 13:03 -0400:
...
I'm OK with having in-tree code not use zapi, but I don't see a win in
propagating all the mess out to the rest of the world. I'll also note
that janitorial deprecation is way too common in the tree today:
people decide they
Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
It is my impression that it was Zope
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Martijn Faassen wrote:
So, my proposal for Zope 3.4:
* have a developer_notes file or directory somewhere.
* let this contain the developer-visible changes.
* it should be focused on how to change your code. That's the important
bit.
In zope/app/publisher/http.zcml we have
class class=zope.publisher.http.URLGetter
require
permission=zope.View
attributes=get __getitem__ __str__ /
/class
I think this should be zope.Public. Otherwise unauthorized users
viewing an untrusted page template will get
baiju m-2 wrote:
This document is maintained as a wiki page, so anyone can edit it.
http://kpug.zwiki.org/WhatIsNewInZope33
This is great! It's probably exactly what we need.
Martin
--
View this message in context:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not prefer if these straight-forward APIs
were continously changing.
I prefer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200:
...
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
But you probably would not prefer if these straight-forward APIs
were
12 matches
Mail list logo
