[
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.
