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

Fri Apr 21 19:56:46 EDT 2006

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 <browser:macro .. /> which whould handle the macro
registration rather then use <browser:page ... />. 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:

<html metal:use-macro="context/@@standard_macros/page">

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 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 at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
> 