click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Md. Jahid Shohel (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CLK-347) Module support
Date Sun, 04 Jul 2010 01:54:51 GMT

    [ https://issues.apache.org/jira/browse/CLK-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884987#action_12884987
] 

Md. Jahid Shohel edited comment on CLK-347 at 7/3/10 9:54 PM:
--------------------------------------------------------------

>>- 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 menuLabel;

     //this can be a listener, or a page instance to forward when the menu is clicked
    //then user does not have to implement listener
     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 HelpMenuClickListenerImpl());
    }
}

class HelpMenuClickListenerImpl implements MenuClickListener {
      public void onMenuClick(String menuLabel, Context context) {
              context.setForward(new HelpPage());
      }
}





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 (which is part of the access
specification of module1). 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, bundled in the same jar) file. And module1 can take
all beans which implements MenuContributor interface. And local contexts can be then imported
into parent context. Where parent context resides inside /WEB-INF/applicationContext.xml

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.

      was (Author: jahid):
    >>- 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: https://issues.apache.org/jira/browse/CLK-347
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>            Reporter: Bob Schellink
>
> Add module support to Click core. Some code has been committed here: 
>   http://click.svn.sourceforge.net/viewvc/click/trunk/sandbox/sabob/plugin/
> 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.


Mime
View raw message