On Wednesday 22 August 2007 10:03, Philipp von Weitershausen wrote:
> Stephan Richter wrote:
> > On Monday 20 August 2007 09:45, Christian Zagrodnick wrote:
> >> Should we fix that?
> > Yes, or just deprecate the menu stuff. ;-)
> I take that smiley as an indicator that you were joking.
I was joking in the sense that I know it will never happen. If I would be a
dictator, it would be gone already.
Many APIs in Zope 3 have undergone 2-3 iterations. The browser menu stuff has
undergone 1 with one additional refactoring to better use the CA and allow
for sub-menu items.
> > The default menu framework was
> > insufficient in every real-world project I have worked on. Menu items
> > based on the context just do not work.
> This is again a recurring theme where a package defines an abstract
> concepts with an interface (named IBrowserMenu utilities) and also ships
> an implementation with it (context-sensitive menu items based on adapters).
It turns out that IBrowserMenu and IBrowserMenuItem are just too heavy. I can
do much better with a viewlet manager as the menu and a viewlet as a menu
> You condemn that one implementation, but the whole point of the
> component architecture is that you can happily create your own
> IBrowserMenu implementation (which I trust you have). So no need to
> throw away that existing context-sensitive implementation.
Yes, I do condemn the implementation, but I also condemn the interfaces. What
I am not condemning is the development/UI pattern of menus. In my projects I
found that the requirements vary widely among menu requirements, which are
not easily modelled in a generic set of interfaces.
> Now, we might think about *separating* the two perhaps, in order to
> reduce dependencies (if you just want the IBrowserMenu concept, you
> might get away with less dependencies)...
I just want to get to the point, where I do not have a dependency on Rotterdam
and all the default browser request registrations, because I am not using
them at all. Generic default browser layer registrations are evil, evil,
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list