click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Malcolm Edgar <malcolm.ed...@gmail.com>
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
constructor.

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 <sabob1@gmail.com> 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 org.apache.click.extras.builder.MenuBuilder 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?:
>> http://tinyurl.com/ycfzxc3
>>
>> Thank you,
>>
>> Adrian.
>>
>>
>
>

Mime
View raw message