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 Sat, 03 Jul 2010 17:08:55 GMT


Md. Jahid Shohel commented on CLK-347:

Before I comment, I must mention that, I am just saying what I think (which is more like discussing).

>- How do you expect the module to become aware of the main application BorderPage? 

If module1 contains the border page, and module2 contains the body page. Then module1 should
depend on module2. That should work right? At least I don't see any reason of not working,
or may be I am missing something.

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

>- How will the module third-party jar dependencies and configurations be handled? 

I am a maven user, I don't see any problem with this. Because when my war is built, all my
dependent jars, and their dependency, and their dependency...... all are packed into the war's
WEB-INF/lib. That does not mean everyone have to use maven, but they can solve it the way
maven does that.

>- What about the module's DataSource? 

Say module1 loads the data source. then the specification of module1 can be, that it puts
the data source into the session with some special key. Then all other modules (who will use
the datasource of module1) can follow the specification of module1, and use the same key to
fetch the datasource from the session.

The other way is, giving a way so that modules can query for other modules, and can get a
hold of the module. That way, all other modules can get hold of module1, and ask for data
source/any other object/services.

>- What about the entities of the module and how will the main application ORM filter influence
the module ORM settings? By this I mean the Open Session In View Filter which is the most
common for web apps. 

Yes this is a problem. I don't have clear answer for this, but some ORM can give a specific

>One can certainly break a big app into smaller modules (Eclipse subprojects), but they
are still part of the same application and are tested as a whole. 

Will that be modularity/plugin? It sounds like more package separation, but not modularity.
Some example or detail description will clear the confusion.

> 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