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 <[email protected]> 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. >> >> > >
