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 Tue, 29 Jun 2010 10:13:51 GMT


Md. Jahid Shohel commented on CLK-347:

I already read that post, and that's how I thought too, that's why I did not mention them
on my earlier post. The requirements I see, and the possibility of solving those with existing
system are mentioned below-

Requirements -

1) Click should have modularity support. Where developers can write their own click modules
and use the same module on different applications.
2) Each module should be self contained with all its resources.
3) Each module should have a way to mention its own configurations. If any specific configuration
is not specified, then it will use the application's configuration. This will give the module
to run with its configurations isolated.
4) A module need to be self contained, so that it should be possible just to plug in a module
without require to modify it before plugging it in.

What we can/can't solve with existing technology (according to requirements sequence)-

1) Current click release does not support modularity at all. So may be we have to start it
from scratch. As per the last solution, we can have a ModuleService which is responsible for
loading all modules. And main application (ClickServlet or any config service) can trigger
the ModuleService to load modules. That way we can keep loading modules separate.

2) For resources, It should work exactly as bob mentioned on earlier post (see above). The
only thing I will suggest is, the module should have a scope to mention its own configuration
with it.

3) There are several way to let the module has its own configuration with it. Right now we
xml approach, and we can share a huge amount of code from xmlconfigservice (will require refactor
xmlconfigservice and separate common logics to share). Using properties or annotations are
other alternatives. In the old solution, it was done by letting user implement/extend a interface/class
and return their own configurations. We can still use that, but this might encourage some
user to hard code their configurations inside the class.

> 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