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:
with this clearer approach:
class SD6AgentsVocab
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 intro
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
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
>> http://dev.zo
[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 prov
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 o
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 IInputWidget.provide
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 w
[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
expre
[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
[EMAIL PROTECTED] wrote:
>> [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,
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 somethin
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 thi
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 futu
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 regi
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 fact
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
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 m
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?
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 th
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.co
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 mea
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 on
[EMAIL PROTECTED] wrote:
> what I like to see is something like:
>
>
>
> 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 python
> factory. The *StandardMacros/page*
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 mentio
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
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 me
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,
[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 bri
29 matches
Mail list logo
