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 > Zope3email@example.com > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com