RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 which makes it possible to use the same naming for ojects and views on a container. Second this is callable via the @@ in page templates. The implementation that we didn't use a tales expression is bad. It doesn't make sense to me that we can automaticly use traversal namespace in tales. I think the API for implement additional functionality is the ITALESExpression interface. Every other implementation which makes something possible in TAL is bad. That's just what I think. > > The implementation of a *provider* > > tales expression for viewlet manager totaly avoids this :-) > > As I said in another post, I think tales expressions are abused there. > For looking up views, would you not use ++view++ but rather a view: > TALES expression? Or for resources? I think not. > > Getting from an object to a view (=view,page,viewlet,etc.) of > this object is traversal. It belongs into a traversal adapter. Yes, I know, but where doe we describe the interface for that? Is there a interface somewhere that I can see why I can call traversal namespace from TAL? Perhaps I missed this till now. How do you explain the TAL implementation of a @@ lookup to someone? Regards Roger Ineichen > Philipp > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[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 >> should be registered unpublishable browser views and not >> browser pages. >> >> You see how far into the confusion the >> directive has brought us? > > 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 implementation of a *provider* > tales expression for viewlet manager totaly avoids this :-) As I said in another post, I think tales expressions are abused there. For looking up views, would you not use ++view++ but rather a view: TALES expression? Or for resources? I think not. Getting from an object to a view (=view,page,viewlet,etc.) of this object is traversal. It belongs into a traversal adapter. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[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
expressions, that means you enter some form of expression and the engine
will resolve the expression. Look at the expression types we had originally:
* path (resolve a/path/like/that)
* string (string ${templating})
* python (evaluate Python code)
In other words, TALES expressions *evaluate* some form of expression
(perhaps even regular expression, SQL, whatever). But using them to
*look up* something seems like abuse to me.
> My context doesn't need to have a ++macro++ namespace!
It has ++view++, ++vh++, etc. namespaces. Why can't it have that namespace?
> My context doesn't know about macros and viewlets.
Right. No one is expecting that. That's exactly what adapters are for.
Your context doesn't know about absolute URLs either, but yet we can say
context/@@absolute_url.
> Macros or viewlets
> depend on context and request. This is the reason why we implemented a
> lookup via tales expression and not a traversal namespace on our context.
That's not a reason. Traversal namespaces also take context and request.
Lots of things take context and request.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
[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 Burt in this thread: >> http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html > > I don't telling that you are not right at all ;-) > It's just not correct to remove the old way of doing. I won't maintain the old code. It's horrid. At some point we'll just have to clean out the attic. That's what deprecation is for. Timed removal. Allowing the old way for a while until it's removed. After all, you'll have one year to fix up your app. We recently agreed on this deprecation period in the community, if I may remind you... >> Now, would you rather make an attempt to document the >> inconsistent (and hard to maintain, not to forget!), or >> wouldn't you rather make an attempt at fixing the damn thing? > > I guess, making the refactoring and support a high level > directive doing the old way will solve the problem. Not sure why you would want to do that. Have you read my proposal at all? Is this tiny base class SUCH a burden that you have to write another high-level directive? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 unpublishable browser views and not > browser pages. > > You see how far into the confusion the > directive has brought us? Yes, but this is only a problem how we lookup views/pages via /@@ in templates. The implementation of a *provider* tales expression for viewlet manager totaly avoids this :-) Regards Roger Ineichen > Philipp > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 > > rather then use a implicit mixin class. > > > > What do you think Philipp? > > This isn't part of the discussion about this proposal. > > Just to be clear: > > * Having to register macros as pages when they're not meant > to be publishable sucks. > > * @@standard_macros sucks a bit too (too much indirection). > It sure confuses people (like Tonico, as he says himself). > > * I'd rather not invent a new ZCML directive nor a new TALES > expression type (I don't like this about viewlets and > contentproviders). > > I could imagine a new traversal namespace: > > > Here, 'page' is an adapter from (context, request) (it's a > view) to IMacro or something. It will also be registered as > such (as a or just an ). > > 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. My context doesn't need to have a ++macro++ namespace! My context doesn't know about macros and viewlets. Macros or viewlets depend on context and request. This is the reason why we implemented a lookup via tales expression and not a traversal namespace on our context. > If we shall discuss this any further, I suggest we move into > a separate thread. Yup > Philipp > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] RE: RFC: The browser:page compromise
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 thread: > http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html I don't telling that you are not right at all ;-) It's just not correct to remove the old way of doing. > Now, would you rather make an attempt to document the > inconsistent (and hard to maintain, not to forget!), or > wouldn't you rather make an attempt at fixing the damn thing? I guess, making the refactoring and support a high level directive doing the old way will solve the problem. Regards Roger Ineichen > Philipp > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[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* knows how to lookup a > registred macro called *page* in the *StandardMacros*. > > See also my (a little old) proposal at: > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMacroRegistration > > Note: the proposal is a little bit old and I whould > change the directive browser:macros and make explicit use of > a python factory rather then use a implicit mixin class. > > What do you think Philipp? This isn't part of the discussion about this proposal. Just to be clear: * Having to register macros as pages when they're not meant to be publishable sucks. * @@standard_macros sucks a bit too (too much indirection). It sure confuses people (like Tonico, as he says himself). * I'd rather not invent a new ZCML directive nor a new TALES expression type (I don't like this about viewlets and contentproviders). I could imagine a new traversal namespace: Here, 'page' is an adapter from (context, request) (it's a view) to IMacro or something. It will also be registered as such (as a or just an ). I think viewlets and contentproviders should have taken the same road and used traversal namespaces. That's what they're for :). If we shall discuss this any further, I suggest we move into a separate thread. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
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, IMO. I also write on Zope 3 and train people. *All* of my recent attempts to make ZCML clearer and easier to understand comes from *direct* feedback from these trainings and from the readers of my book. 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 thread: http://mail.zope.org/pipermail/zope3-dev/2006-April/019169.html Now, would you rather make an attempt to document the inconsistent (and hard to maintain, not to forget!), or wouldn't you rather make an attempt at fixing the damn thing? Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 very hard to fit the pices to a big picture. Perhaps it whould help if we have another directive ;-) called which whould handle the macro registration rather then use . This whould let us use some concept of a explicit *philiKON* factory for macro registrations which makes the standard_macros mapping a little more transparent. 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. This could look like: Macro lookup right now: 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* knows how to lookup a registred macro called *page* in the *StandardMacros*. See also my (a little old) proposal at: http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SimplifyMac roRegistration Note: the proposal is a little bit old and I whould change the directive browser:macros and make explicit use of a python factory rather then use a implicit mixin class. What do you think Philipp? > I like Philipps proposal because it tries to remove some of > that magic that makes it often difficult to understand (or to > accept) the concept. > > > Do yo have a simpler naming and/or module/package structure > concept in > > mind? If so, is this not only a part of a project or > application like > > a CMS etc? Do you think UI Developers should work out of > the box with > > a Zope3 instance? > > Not at the moment. > > > A browser request offers a API for collecting browser (client) > > releated informations like charset settings. This is done via the > > interface IUserPreferredCharsets. > > Interesting, does it also offer an API for preferred language > and preferred media? There is a adapter providing the interface IUserPreferredLanguages which can be used on requests. This adapter reads the request value *HTTP_ACCEPT_LANGUAGE* in the method *getPreferredLanguages*. The adapter is registred for the IHTTPRequest. > > A browser request also deals with form data and collects the given > > form input into a FieldStorage object. The most important > part here is > > that a browser request knows how to handle file upload. > > Interesting. > > > The browser request is based on the http request which does > the base > > stuff like cookie handling etc. > > Thanks for explanation. no problem Regards Roger Ineichen > Tonico > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
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 changing the old ones. Right? > > Yes, I think it's very important to bring a little stability to the > Zope3 framework rather then change every release such fundamental > parts like directives. FWIW, +1 on not changing the old directives. and +1 on introducing less magical directives and, eventually, deprecating and removing the old magical directives. -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" damm, I really need a new quote... ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
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 warning telling me what I should do instead is great. There should be a link in the CHANGES.txt file to the original proposal for each change. If there is no time to update it after discussions take place, then why not cut and paste an excerpt from the relevant email thread into the CHANGES file? Or at a minimum how about a URL link to the start of the dev-list discussion thread. my 2c, --Craeg 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, IMO. - Kamal Yes, I think it's very important to bring a little stability to the Zope3 framework rather then change every release such fundamental parts like directives. Regards Roger Ineichen -- Kamal Gill - [EMAIL PROTECTED] http://www.adaptivewave.com Content Management Made Simple direct: +1.916.679.4123 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/cstrong%40arielpartners.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 contain he ever will be able to understand what he has to do in ZCML? (I guess this is really not a naming problem) Do yo have a simpler naming and/or module/package structure concept in mind? If so, is this not only a part of a project or application like a CMS etc? Do you think UI Developers should work out of the box with a Zope3 instance? > >> How is a browser defined in Zope 3 and how are these names > related to > >> it? > > [...] > > > All of this directive are based on the IBrowserRequest. > > Other requests like FTPRequest don't have a menu layer etc. > > How is a BrowserRequest different from a HTTPRequest? A browser request offers a API for collecting browser (client) releated informations like charset settings. This is done via the interface IUserPreferredCharsets. A browser request also deals with form data and collects the given form input into a FieldStorage object. The most important part here is that a browser request knows how to handle file upload. The browser request is based on the http request which does the base stuff like cookie handling etc. Regards Roger Ineichen > Tonico > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 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's going on behind the scenes. > > 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 structure like: package browser For other request types like FTPRequest, XMLRPC or JSON etc we use: package ftp xmlrpc json Perhaps this is to technical and will confuse people which don't know the base concepts of request type interfaces. But since no tehchnical peple have no chance to develope with z3 I think this naming is OK. > How is a browser defined in Zope 3 and how are these names > related to it? > > addMenuItem > addform > containerViews > defaultSkin > defaultView > editform > form > i18n-resource > icon > layer > menu > menuItem > menuItems > page > pages > resource > resourceDirectory > schemadisplay > skin > subMenuItem > subeditform > tool > view > viewlet > viewletManager All of this directive are based on the IBrowserRequest. Other requests like FTPRequest don't have a menu layer etc. The exception zope:view doesn't use a implicit request this is the reason why the zope:view is also existent next to the browser:view. This means the zope:view directive can be used together with a different request then IBrowserRequest. > What is a page? Is a dynamic stylesheet or a dynamic > javascript or an Atom feed a page? Does a page provide a > mime_type? Should a page do content negotiation? More or less all of this is a adapter called on a context and request providing a interface and a optional name producing a response ;-) Remember page is a replacement for the earlier name *presentation" which was a little bit a to long naming. > Create a new clean namespace and call it user_interface (or ui)! :) I think a name like ui doesn't reflect the request type and will be a bad idea for register *presentations* for json which are registred like right now. But if you like to use etc, you can do this by simply setting the namspace to: xmlns:ui="http://namespaces.zope.org/browser"; And then use btw, I whould like to use only one directive called *zope* for all directives. The directive *browser* is not really needed except for let us use zope:view and browser:view ;-) Regards Roger Ineichen > Tonico > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: RFC: The browser:page compromise
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 Yes, I think it's very important to bring a little stability to the Zope3 framework rather then change every release such fundamental parts like directives. Regards Roger Ineichen -- Kamal Gill - [EMAIL PROTECTED] http://www.adaptivewave.com Content Management Made Simple direct: +1.916.679.4123 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: The browser:page compromise
[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 releases, could be more). > > I don't like the proposal and the direction where you are > Going, but this is another part. Not sure what you mean by that... > But I'm fine with this changes as long as the browser:page > directive doesn't change in any way. That confuses me even more. I *am* proposing changes to the browser:page directive... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Re: RFC: The browser:page compromise
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 be more). I don't like the proposal and the direction where you are Going, but this is another part. But I'm fine with this changes as long as the browser:page directive doesn't change in any way. Regards Roger Ineichen > Philipp > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
