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 depr
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 tr
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 t
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 usef
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 the
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
>
In zope/app/publisher/http.zcml we have
I think this should be zope.Public. Otherwise unauthorized users
viewing an untrusted page template will get errors from a template
that tries to do things like tal:attributes="action request/URL".
A non-public permission is particularly
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:
http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.htm
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 pr
-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 wo
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 conti
12 matches
Mail list logo
