click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <>
Subject Re: Static menu methods
Date Sat, 06 Mar 2010 08:56:45 GMT
I think the builder pattern is better than the static factory pattern
as you can easily subclass a builder to modify the creation behaviour.
This is harder to do with static factory methods.  However we do need
a static object to hold a cached root menu instance. I think this
could be exposed as a protected property on a MenuBuilder class.

One good builder patten I have used it to be able to optionally pass
in the class of the object you want created. For example:

MenuBuilder menuBuilder = new MenuBuilder();

Menu rootMenu = menuBuilder.getRooMenu(AcmeMenu.class);

With this pattern the Menu tree created would be composed of AcmeMenu
instances. This requires these Menu subclasses to provide a no args

I do note using the builder pattern requires a couple of lines of
code, rather than just one line of code as with static factory
methods. However in applications I generally have the menu added in a
BorderPage sublcass.

regards Malcolm Edgar

On Sat, Mar 6, 2010 at 2:52 PM, Bob Schellink <> wrote:
> Builders cater for a different problem from the one we are trying to solve.
> We need to make Menu easier to subclass for application specific use cases,
> and this basically means getting rid of the static methods.
> I suggest a MenuFactory singleton as it is more suited for loading menus
> from an external file and for storing menus in different scopes.
> kind regards
> bob
> On 4/03/2010 11:34 PM, Adrian A. wrote:
>>> With regard to the Menu creation. I would like to see a builder
>>> pattern used. I have used this in a work application and I am very
>>> happy with the results. The builder class can also support alternative
>>> caching options (CLK-405)
>> Could you please attach that MenuBuilder to one of the menu issues ?
>> (In CLK-405 you mention a Factory pattern in the comment instead of the
>> Builder pattern)
>>> In terms of rolling this pattern into Click, I would suggest a 2 step
>>> strategy:
>>> version 2.2 add class and
>>> depreciate the static factory methods on the Menu class
>>> version 2.3 or 2.4 remove the static factory methods on the Menu class
>> OK, I'll do it so.
>> I will also update the click-examples and QuickStart to use this new
>> approach.
>>> In terms of adding arbitrary properties to the Menu class (CLK-407),
>>> we could dynamically load other properties (visible, enabled, etc.)
>>> from Menu XML attributes.
>> I already checked those in.
>> There remains only the question of propagating or not the properties in
>> the child nodes too?:
>> Thank you,
>> Adrian.

View raw message