Hi Roger,
On Sat, 22 Apr 2006 01:56:46 +0200, dev wrote:
What I really dislike
on the browser:page registration for macros, is, that such macros are also
callable as traversable views rigth now. I whould like to see a different
lookup for macros in the future.
That was one of my first
[EMAIL PROTECTED] wrote:
That confuses me even more. I *am* proposing changes to the
browser:page directive...
Hmm, never mind. I think I understand what you mean. You'd
like to see new directives, instead of changing the old ones. Right?
Yes, I think it's very important to bring a little
Kamal Gill wrote:
Stability is especially important for those of us learning Zope 3, as
well as those who offer Zope 3 training. I realize Z3 is a fast-moving
target, but making existing books and documentation obsolete doesn't
help the adoption of such a fantastic collection of software,
Tres Seaver wrote:
- Deprectaion of an older, stable alternative, *no matter how grotty,*
should go hand in hand with *lots* of confidence that the new favored
alternative really is superior, and by enough margin to make the
switch worthwhile. In my mind, this means that the new
Bernd Dorn wrote:
http://dev.zope.org/Zope3/TheBrowserPageCompromise
[snip]
-1
In the Proposal you say:
Why is this a problem? Because certain behaviour is mixed into the
class created on-the-fly. This behaviour is not apparent in our view
class, yet we assume it exists. It's magic.
Thanks to everyone who commented on the first versions of this proposal.
People seem to object changing the old directives. I respect that.
I've therefore changed the proposal to introduce *new* directives. See
http://dev.zope.org/Zope3/TheBrowserPageCompromise once again. Note that
I'm not
[EMAIL PROTECTED] wrote:
what I like to see is something like:
html metal:use-macro=macro:StandardMacros/page
Such a macro could be lookuped by a ITALESExpression
called *macro* similar to the IContentProvider implementation.
The *StandardMacros* could be a mapping registred as a
Balazs Ree wrote:
On Sat, 22 Apr 2006 01:56:46 +0200, dev wrote:
What I really dislike
on the browser:page registration for macros, is, that such macros are also
callable as traversable views rigth now. I whould like to see a different
lookup for macros in the future.
That was one of my
I'm -1 on this proposal.
I agree, browser:page is too complex and magic. The reason for it's
complexity and magic is that there are two things that clash: 1. The
need to have simple and easy view registrations, and 2. The
requirement that view must be callable classes.
The second requirements
On 4/21/06, Jim Fulton [EMAIL PROTECTED] wrote:
I'm wondering if this is a problem.
I'd say that as long as the register API adds them to the nearest site
manager it is not a problem that you can add it anywhere else if you
don't use that API.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
Lennart Regebro wrote:
On 4/21/06, Jim Fulton [EMAIL PROTECTED] wrote:
I'm wondering if this is a problem.
I'd say that as long as the register API adds them to the nearest site
manager it is not a problem that you can add it anywhere else if you
don't use that API.
The point is that the
Hi, folks!
On Fri, Apr 07, 2006 at 05:23:06PM +0200, Philipp von Weitershausen wrote:
The Maildir step could have been skipped, I suppose, just the
connection to a mail server directly over the network interface would
suffice. Is there a specific reason for the Maildir implementation?
Hi Philipp
-Original Message-
From: Philipp von Weitershausen [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 22, 2006 9:15 AM
To: [EMAIL PROTECTED]
Cc: zope3-dev@zope.org
Subject: Re: RFC: The browser:page compromise
[EMAIL PROTECTED] wrote:
That confuses me even more. I *am*
Hi Philipp
ZCML as of Zope 3.2 is inconsistent and to someone who's new
and doesn't know every little detail from behind the scenes
it's very obscure. And then it also makes debugging hard
which has bitten me personally quite a few times. I explained
this is a reply to Rocky Burt in this
Hi Philipp
See also my (a little old) proposal at:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Simpl
ifyMacroRegistration
Note: the proposal is a little bit old and I whould change the
directive browser:macros and make explicit use of a python factory
Hi Philipp
IMO it would be great to solve this properly, because one point of
using views is to have a fine control over what to publish
and what not.
And this is a bit broken at this point, currently.
Right, that's why page templates that just provide macros
should be registered
Hi Balazs
Hi Roger,
On Sat, 22 Apr 2006 01:56:46 +0200, dev wrote:
What I really dislike
on the browser:page registration for macros, is, that such
macros are
also callable as traversable views rigth now. I whould like
to see a
different lookup for macros in the future.
That
Lennart Regebro wrote:
On 4/22/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
The point is that the registration API doesn't add anything. It just
registers.
Oh, so you still have to add and register separately? That sucks.
You currently do as well. I think that's a good thing. In
On 4/22/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
You currently do as well. I think that's a good thing. In Zope 2
something was registered by simply being there. In the CMF, for
example, you can't disable a tool unless you remove it or move it. Being
registered is something
[EMAIL PROTECTED] wrote:
ZCML as of Zope 3.2 is inconsistent and to someone who's new
and doesn't know every little detail from behind the scenes
it's very obscure. And then it also makes debugging hard
which has bitten me personally quite a few times. I explained
this is a reply to Rocky
[EMAIL PROTECTED] wrote:
I think viewlets and contentproviders should have taken the
same road and used traversal namespaces. That's what they're for :).
I don't think so.
ITALESExpression are built for this use case.
I doubt that they were designed to *look up* things. They're
On Sat, Apr 22, 2006 at 01:27:36PM +0300, Marius Gedminas wrote:
Actually, the DirectMailDelivery utility also aborts emails if the
transaction is aborted. The reason for using Maildirs was to speed up
the transaction commit -- if you send 100 emails in a transaction, you
do not want to wait
The formlib.EditForm dosen't catch all errors form widgets.
The following method catches only InputError:
def getWidgetsData(widgets, form_prefix, data):
errors = []
form_prefix += '.'
for input, widget in widgets.__iter_input_and_widget__():
if input and
Philipp von Weitershausen wrote:
Thanks to everyone who commented on the first versions of this proposal.
People seem to object changing the old directives. I respect that.
I've therefore changed the proposal to introduce *new* directives. See
http://dev.zope.org/Zope3/TheBrowserPageCompromise
[EMAIL PROTECTED] wrote:
Hi Philipp
IMO it would be great to solve this properly, because one point of
using views is to have a fine control over what to publish
and what not.
And this is a bit broken at this point, currently.
Right, that's why page templates that just provide macros
Florent Guillaume wrote:
Philipp von Weitershausen wrote:
Thanks to everyone who commented on the first versions of this proposal.
People seem to object changing the old directives. I respect that.
I've therefore changed the proposal to introduce *new* directives. See
Hi Philipp
Yes,
but this is only a problem how we lookup views/pages via /@@ in
templates.
That's how we lookup views. @@ is short for ++view++.
Traversal namespaces are the way to lookup things that are
not direct attributes.
The namespace ++view++ is in the first line a namespace
On Sat, Apr 22, 2006 at 06:28:35PM +0200, Florent Guillaume wrote:
Philipp von Weitershausen wrote:
Thanks to everyone who commented on the first versions of this proposal.
People seem to object changing the old directives. I respect that.
I've therefore changed the proposal to introduce
28 matches
Mail list logo
