[Seaside] Refactoring menu bar code for Seaside App..

[Sean Allen]

On Mon, Aug 16, 2010 at 6:37 PM, Rick Flower <rickf at ca-flower.com> wrote:
> On Mon, 16 Aug 2010 16:45:55 -0400, Sean Allen
> <sean at monkeysnatchbanana.com> wrote:
>> I would create actual menus for each type of menu so you can work with
>> objects rather than a list of items and blocks.
>> I find objects/components much easier to refactor, debug etc.
>
> So, create an object for each menu?  My old code used something
> similar with class side methods indicating whether the menu
> was applicable for each type of user or not.. I'm just trying to
> find a nice clean way to implement a lot of different menus.

My first thought would be:

A component for each type of menu. Then a general menu component that
could double dispatch on the type of user to determine which menu
component to use.

>
> By the way.. The method I referenced from the Seaside blog
> tutorial earlier was (I believe) based on the material from
> this post :
> http://miguel.leugim.com.mx/index.php/2008/01/03/seaside-menus/
>
> I was perusing through the list archives and found an interesting
> discussion back in 2008 regarding menu components and the use
> of announcements.. I need to read up on them again as I'd really
> like to better know what they're doing under the hood and to
> possibly find a short example of their use with regards to a menu
> system.. They're one of those scratch-my-head areas that I'm not
> comfortable with yet..
>

Announcements are basically the observer pattern from GOF.

+: loose coupling
-: can be a nasty pain to debug

You can google and find tons of pro and con on the observer pattern.
That should give you plenty of info to evaluate the general
publish/subscribe idea.

I found that general idea to be very useful when I used to do C++ GUI
development
but haven't had any need for it when using Smalltalk. Then again, I've
only been doing Smalltalk
for 2 years.