Re: [Zope3-dev] Re: One namespace for ZCML
Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). 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: One namespace for ZCML
Hi Philipp [...] Subject: Re: [Zope3-dev] Re: One namespace for ZCML Roger Ineichen wrote: I'm interessted in a menu / menu item refactoring. This means, we could get rid of the implicit magicly registred menus in other directives which ends in unaccessible menu items and will offer a better accessible API. I will write a proposal later, but perhaps I have to prototype first since this part is very complex and used almost in every browser directive. Note that my other proposal, ReducingTheAmountOfZCMLDirectives, mentions something like this in the end (it's not really part of the actual proposal anymore, just some random thoughts): Many directives of the browser namespace support the registration of menu items in addition to registering the component in question. Though this can be considered useful because it might save some typing, keeping directives as simple as possible (on/off switches!) might be weighed higher. People are certainly intimidated by the length of some of the browser directives (such as browser:editform); by taking the menu functionality out, we could reduce many directives by two lines making them easier to understand by themselves (of course, we'll have to add another menu directive, but it'll only be 3 or so lines). Yes, I agree, that's also a good base for a menu simplyfication. If you got any further comments on this, I'd be happy to hear them. It doesn't *have* to be a proposal, but it would sure be nice :). I think it's to complex it right now since I'm not sure at all if my idea will work. Let me try to give a short overview. - Merge the menu and menu item to one implementation - the above will also allow to implement nested menus. Right now the implicit menu, registred in views, don't have a id itself. This means they are unuseful for nested menu registrations. - move menu registration out of the view directives, (like described in your proposal) - Also refactor the IFactory concept. Use IFactory adapters on folders instead of IFactory utilities. The last part IFactory adapters instead of IFactory utilities depends on a application I wrote and was running in serious problems because of the slowdown which depends on IFactory utilies lookups. I'm not sure if somebody will agree on this, but I think if I can profile the IFactory utility implementation and show the slowdown, we have a better base for a proposal. This would also solve some namespace problems we have with the content type name registration. Note; nested menus are implemented since more then a half year. But they are not useable with the existing menu items which are registered inculded in the view directives. Because in the view directive registred menus are only menu items which are not nested. 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: One namespace for ZCML
On Feb 13, 2006, at 10:05 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote: [...] +1 to Stephan's comment, Tres' comment, and Tres' use of the word ukase (which I had to look up). -1 to the proposal. Gary ___ 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: One namespace for ZCML
On Monday 13 February 2006 10:05, Tres Seaver wrote: - I don't want to encourage people to do configuration in Python: we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the ZCML delenda est thread. - The application vs plugin discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. - Many of the objected-to directives exist precisely because people did not want to type the much more verbose equivalents which were the original, cleaner spellings. Mmmh, I had totally forgotten about this design goal/use case. Thanks a lot for pointing this out. I will not change my vote on the other proposal, but I think we have to keep this in mind when talking about ZCML simplification. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: One namespace for ZCML
Hey, Good comments, Tres, thanks. Regards, Martijn ___ 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: One namespace for ZCML
On 2/13/06, Sidnei da Silva [EMAIL PROTECTED] wrote: Someone argued in the python-brasil list that let's do more of those actually refers to 'one honking great idea', thus meaning let's do more of those great ideas (like namespaces). This is the first time I've heard that interpretation. Now whether that's that's the correct interpretation is up to the original author (Tim Peters?) to clarify :) I don't know if he's paying attention to this thread, but I'm fairly certain everyone at PythonLabs understood that to refer to namespaces. If Tim would like to counter that, he's certainly free to do so, of course. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ 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: One namespace for ZCML
Quick in-and-out from a lurker: yesterday as I was learning how to use Five with Plone, I thought to myself, wouldn't it be cool if there were two directives, cmf:installable and cmf:registerContentClass? This is from someone who's totally naive about zcml. Was this evil on my part? Because the debate seems to be about behaviors that are implicitly encouraged. Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a plone:view directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing site policy by customizing software. -- -J. Method ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
