- A name or identifier
- A list of other modules it needs
<gatein-resources> <module> <name>customerModule</name> <script> <path>/customer.js</path> </script> </module> <module> <name>orderModule</name> <script> <path>/order.js</path> </script> </module> <module> <name>applicationModule</name> <script> <path>/application.js</path> </script> <depends> <module>customerModule</module> <depends> <depends> <module>orderModule</module> <depends> </module> </gatein-resources>
The resource descriptor file tells GateIn about our modules and how they are connected to each other. After this short introduction to modules, we will explain the benefits of modularity.
Modularity is the silver bullet for solving this problem because it gives proper isolation between modules. In our example, the module system will inject the customer and order modules into the application module.
Furthermore several versions of the same library can be used at the same time. GateIn 3.5 is built with jQuery. Thanks to modules, you can use the jQuery of your choice without conflicting with GateIn’s jQuery.
Modules are natural constructs for building modular applications. Common code can be extracted into a module, allowing the code to be reused.
Last but not least, modularity leads to excellent front-end performance because the loading of modules can be optimized by GateIn:
- Lazy loading: What is more efficient than not loading a resource? Modules can be lazy and loaded when required by a portlet or a portal at the most appropriate time instead of using page headers that block page rendering.
- Parallel loading: Modules that don’t depend on each other can be loaded at the same time.