You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by Bob Schellink <sa...@gmail.com> on 2010/03/04 11:06:40 UTC
Static menu methods
Hi Adrian,
The static methods on Menu is proving quit problematic when extending the Menu control. I suggest we
don't add static methods but rather look at other ways to building the Menu which also allows easy
subclassing for custom features.
kind regards
bob
Re: Static menu methods
Posted by Malcolm Edgar <ma...@gmail.com>.
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 <sa...@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.
>>
>>
>
>
Re: Static menu methods
Posted by Bob Schellink <sa...@gmail.com>.
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.
>
>
Re: Static menu methods
Posted by "Adrian A." <a....@gmail.com>.
> 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.
Re: Static menu methods
Posted by Malcolm Edgar <ma...@gmail.com>.
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)
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
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.
regards Malcolm Edgar
On Thu, Mar 4, 2010 at 9:21 PM, Adrian A. <a....@gmail.com> wrote:
>
>> The static methods on Menu is proving quit problematic when extending
>> the Menu control. I suggest we don't add static methods but rather look
>> at other ways to building the Menu which also allows easy subclassing
>> for custom features.
>
> Hmm, there's no other easy/nice way IMHO, or a total refactoring of the Menu
> class would be required.
>
> The main problem is that the Menu is in fact a self referenced MenuItem.
>
> This causes allot of confusion among users, and IMHO it's why is so hard to
> extend too by users. It's also missing some user usable ID, since the path
> must not be unique (i.e. more menu items could point to the same path).
>
> Maybe a better way would be to have Menu and MenuItem classes (similar to
> Swing and other frameworks). This way there would be no need for static
> methods at all.
>
> Adrian.
>
>
Re: Static menu methods
Posted by "Adrian A." <a....@gmail.com>.
> The static methods on Menu is proving quit problematic when extending
> the Menu control. I suggest we don't add static methods but rather look
> at other ways to building the Menu which also allows easy subclassing
> for custom features.
Hmm, there's no other easy/nice way IMHO, or a total refactoring of the
Menu class would be required.
The main problem is that the Menu is in fact a self referenced MenuItem.
This causes allot of confusion among users, and IMHO it's why is so hard
to extend too by users. It's also missing some user usable ID, since the
path must not be unique (i.e. more menu items could point to the same path).
Maybe a better way would be to have Menu and MenuItem classes (similar
to Swing and other frameworks). This way there would be no need for
static methods at all.
Adrian.