[Zope3-dev] RE: Re: RFC: The browser:page compromise

2006-04-22 Thread Balazs Ree
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

[Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
[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

Re: [Zope3-dev] RE: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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,

[Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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.

[Zope3-dev] Update: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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

Re: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
[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

[Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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

Re: [Zope3-dev] RFC: The browser:page compromise

2006-04-22 Thread Lennart Regebro
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

Re: [Zope3-dev] RFC: Components in content add menus

2006-04-22 Thread Lennart Regebro
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/

[Zope3-dev] Re: RFC: Components in content add menus

2006-04-22 Thread Philipp von Weitershausen
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

Re: [Zope3-dev] Re: ZOPE3 Maildir implementation

2006-04-22 Thread Marius Gedminas
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?

[Zope3-dev] RE: RFC: The browser:page compromise

2006-04-22 Thread dev
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*

RE: [Zope3-dev] RE: RFC: The browser:page compromise

2006-04-22 Thread dev
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

RE: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread dev
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

RE: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread dev
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

RE: [Zope3-dev] RE: Re: RFC: The browser:page compromise

2006-04-22 Thread dev
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

[Zope3-dev] Re: RFC: Components in content add menus

2006-04-22 Thread Philipp von Weitershausen
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

[Zope3-dev] Re: RFC: Components in content add menus

2006-04-22 Thread Lennart Regebro
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

Re: [Zope3-dev] RE: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
[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

Re: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
[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

Re: [Zope3-dev] Re: ZOPE3 Maildir implementation

2006-04-22 Thread Pjotr Prins
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

[Zope3-dev] Formlib error handling

2006-04-22 Thread dev
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

[Zope3-dev] Re: Update: The browser:page compromise

2006-04-22 Thread Florent Guillaume
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

Re: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
[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

[Zope3-dev] Re: Update: The browser:page compromise

2006-04-22 Thread Philipp von Weitershausen
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

RE: [Zope3-dev] Re: RFC: The browser:page compromise

2006-04-22 Thread dev
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

Re: [Zope3-dev] Re: Update: The browser:page compromise

2006-04-22 Thread Andreas Reuleaux
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

[Zope3-dev] simplifying ZCML by adding properties plus other ideas

2006-04-22 Thread Sam Stainsby
Hi all, I have read the Reducing the amount of ZCML directives proposal with some interest and general agreement, although as a relative Zope 3 newbie I haven't used the full range of directives yet. The deprecation of this confusing markup: vocabulary name=SD6 Agents