-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> 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 creat
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> Is using a convenience base class really that much more complexity for
> the user? It's perhaps a little more typing, but it gives you less magic
> in return. Less magic is less complexity in a way.
Depends on what you mean with "c
Lennart Regebro wrote:
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
A publishable view must provide IBrowserPublisher. We happen to call
such browser views "pages". This requirement and this nomenclature has
worked well since very early days of Zope 3. I'm not suggesting to
c
On 4/23/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
> A publishable view must provide IBrowserPublisher. We happen to call
> such browser views "pages". This requirement and this nomenclature has
> worked well since very early days of Zope 3. I'm not suggesting to
> change that.
>
> I'
Lennart Regebro wrote:
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.
A
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
[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
[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,
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
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*
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
Hi Tonico
> I once tried to understand how the default skin works --
> after that I gave up the idea of creating a new ZMI skin
> myself. (Especially the MacroMagic was difficult to
> understand, but I want to try again someday).
I see, I personaly like macros, but it is true, sometimes
it is
On Fri, Apr 21, 2006 at 01:03:58AM +0200, [EMAIL PROTECTED] wrote:
> Hi Philipp
>
> > > 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 cha
Yes, but speaking as another Zope3 learner, consistency and simplicity
(is "orthogonality" a word?) of the model/API is extremely important
too. I am in favor of such simplifying changes, as long as they are
properly documented and deprecation is properly applied.
For example: a deprecation war
[EMAIL PROTECTED] schrieb:
Hi Tonico
At some point it will be necessary to make the framework
understandable for "normal" UI designers or we'll stick with
ugly user interfaces forever :)
I think it's pretty clear right now. Do you really think if
soembody don't understand what a folder json
Hi Tonico
> At some point it will be necessary to make the framework
> understandable for "normal" UI designers or we'll stick with
> ugly user interfaces forever :)
I think it's pretty clear right now. Do you really think if
soembody don't understand what a folder json or browser should
conta
[EMAIL PROTECTED] schrieb:
The name "browser" for a namespace sux IMHO ;)
The idea of a namspace called browser is the following:
We use the namespace browser for *presentations* (the earlier
name for pages) which depends on the IBrowserRequest.
This is also reflected in the package structur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> 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, an
Hi Tonico
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Tonico Strasser
> Sent: Friday, April 21, 2006 2:10 AM
> To: zope3-dev@zope.org
> Subject: [Zope3-dev] Re: RFC: The browser:page compromise
>
> Philipp von W
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,
IMO.
- Kamal
Philipp von Weitershausen schrieb:
I also think it makes it hard to understand. In response to this
proposal, several people have asked me "By the way, what's the
difference between and anyhoo?" That
alone has proven my point that the current system makes it absolutely
incomprehensible of what'
Hi Philipp
> > 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 st
Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> Tres Seaver wrote:
>>>
- Introducing new deprecation warnings in "third-dot" releases is
probably inappropriate:
>>>
>>> When we have we done this?
>
> 2.9.1 just did it (see below).
>
- Deprecating an API without cleaning
Philipp von Weitershausen wrote:
> [EMAIL PROTECTED] wrote:
>>> I'll be fine with creating new directives instead of changing
>>> the old ones, if that's what the majority prefers. But then
>>> I'd very much like to see a Death Certificate for the old
>>> directives made out for some time in the
[EMAIL PROTECTED] wrote:
>> I'll be fine with creating new directives instead of changing
>> the old ones, if that's what the majority prefers. But then
>> I'd very much like to see a Death Certificate for the old
>> directives made out for some time in the future (doesn't have
>> to be 2 relea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>
>> - Introducing new deprecation warnings in "third-dot" releases is
>> probably inappropriate:
>
>
> When we have we done this?
2.9.1 just did it (see below).
>> - Deprecating an API witho
Hi Philipp
[...]
> I'll be fine with creating new directives instead of changing
> the old ones, if that's what the majority prefers. But then
> I'd very much like to see a Death Certificate for the old
> directives made out for some time in the future (doesn't have
> to be 2 releases, could
Tres Seaver wrote:
-1 on breaking ZCML in the wild. Propose *new* directives which have
new semantics, but for existing directives, we should clean up the
implementation rather than modifying semantics. E.g., we should be able
to rip out the gunk which synthesizes new classes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>
>>-1 on breaking ZCML in the wild. Propose *new* directives which have
>>new semantics, but for existing directives, we should clean up the
>>implementation rather than modifying semantics. E.g
On Thu, 2006-20-04 at 20:16 +0200, Philipp von Weitershausen wrote:
> > Ok, this makes sense. But, the "browser view" you describe (something
> > never published but still looked up from code and used) is exactly how I
> > tend to use template-less 's.
>
> That's why the difference wasn't clear i
Rocky Burt wrote:
> On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote:
>> A browser page is something that's published. It provides
>> IBrowserPublisher and returns some data to the pbulisher that's in turn
>> returned to the agent.
>>
>> A browser view is something more general. @
On Thu, 2006-20-04 at 19:26 +0200, Philipp von Weitershausen wrote:
> A browser page is something that's published. It provides
> IBrowserPublisher and returns some data to the pbulisher that's in turn
> returned to the agent.
>
> A browser view is something more general. @@absolute_url is a brows
Tres Seaver wrote:
> Philipp von Weitershausen wrote:
>>> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>>>
>>> I've long been thinking about how to make simpler and
>>> less magical. Some radical ideas weren't received well and I couldn't
>>> convince even myself 100% that they were the way
Rocky Burt wrote:
> On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote:
>> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>>
>> I've long been thinking about how to make simpler and
>> less magical. Some radical ideas weren't received well and I couldn't
>> convince even myself
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>
> I've long been thinking about how to make simpler and
> less magical. Some radical ideas weren't received well and I couldn't
> convince even myself 100% that t
On Thu, 2006-20-04 at 18:56 +0200, Philipp von Weitershausen wrote:
> http://dev.zope.org/Zope3/TheBrowserPageCompromise
>
> I've long been thinking about how to make simpler and
> less magical. Some radical ideas weren't received well and I couldn't
> convince even myself 100% that they were the
44 matches
Mail list logo
