click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel (JIRA)" <>
Subject [jira] Commented: (CLK-347) Module support
Date Sun, 04 Jul 2010 01:50:49 GMT


Md. Jahid Shohel commented on CLK-347:

>>- How will the module plug into the main application menu system?

>I do not have clear answer for that, because this includes fine grained modularity. By
that I mean, module1 is >the host of main menu, and module2 want to contribute a menu item
on the main menu. But still We can have >modularity, where module1 has the base page, and
module2 has the body pages. So module2 depends on >module1. 

I was actually thinking about this issue, and was wondering, whether we can solve the issue
this way-

Module1(the module that host's menu):

Declares an interface like -

interface MenuContributor {

     public MenuItem contributMenuItem();

class MenuItem {
     private String menuItem;

     //this can be a listener, or a page instance to forward when the menu is clicked
     private MenuClickListener;

    ///constructor and getters setters just like POJO

Module2 (the module which contributes to menu):

class HelpPageMenuContributor implements MenuContributor {
    public MenuItem contributeMenuIItem() {
            return new MenuItem("Help", new MenuClickListenerImpl());

class MenuClickListenerImpl implements MenuClickListener {
      public void onMenuClick(String menuLabel, Context context) {
              context.setForward(new MyPage());

Now, how module1 can find all MenuContributor is a separate issues. And can be solved several
ways -

1) Module1 an put an instance of a class, with specific name. Other modules can take that
instance and register their menu contributor like -

menuRegister.registerMenuContributor(new HelpPageMenuContributor());

2) Using spring, this is much easier. module2 can make HelpPageMenuContributor  a bean on
this local context (i mean child context) file. And module1 can take all beans which implements
MenuContributor interface.

3) Follow the same way as #1 mentioned above, and module1 can implement a ServletContextAttributeListener
and listen to the attribute changes to update the menu. Where as module2 is the potential
candidate to update the attribute with new menu item.

All these are just thoughts. And I believe, we can solve other issues as well. But if Click
can have droppable jar modularity then it will be awesome. We might not be able to bring in
everything all at once, but we can bring in things incrementally.

> Module support
> --------------
>                 Key: CLK-347
>                 URL:
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>            Reporter: Bob Schellink
> Add module support to Click core. Some code has been committed here: 
> Note that with the recent work done on CLK-343 the module code wont compile anymore.
> A related issue is: CLK-328

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message