[Zope3-dev] Re: browser:page's for="" can be class browser:menuItem can't

2007-08-22 Thread Stephan Richter
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 
item.

> 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, 
evil.

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



[Zope3-dev] Re: browser:page's for="" can be class browser:menuItem can't

2007-08-22 Thread Philipp von Weitershausen

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.

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).


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.


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)...



--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: browser:page's for="" can be class browser:menuItem can't

2007-08-20 Thread Philipp von Weitershausen

Christian Zagrodnick wrote:

Hoi

I just figured, that the browser:menuItem cannot be registered for 
classes. But you can with browser:page. I think if a browser:page can be 
registered for a class a menuItem should support this, too.


Also a  will break on getting 
the menu items because the implementation doesn't support classes.


Should we fix that?


Absolutely.


--
http://worldcookery.com -- Professional Zope documentation and training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com