[
https://issues.apache.org/jira/browse/CLK-347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12884950#action_12884950
]
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 answer.
>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: 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.
