Modules

One of the core aspects of the InterJinn framework is its approach to multi-tier application development. This principle used here provides for an interface to create logical separation of code, a high level of code re-usability, and the ability to arbitrarily change core aspects of an application without modifying the code itself. To facilitate this concept, applications consist of modules, which in turn consist of components. These components constitute the actual code written to perform a function. Given this, a module is really a description of how components are bound together. For instance imagine a news application which requires that data be read from some location, then processed, then rendered for display on someone's browser. Each of these aspects can be broken into a component. One might create a data component to retrieve the news content from a remote site, a logic component to process the data (perhaps it needs to be cleansed), and a render component to mark up the news content to some desired format (later you'll see how to optionally maintain layout in templates rather than in the component).

What does this mean to me?

So far I've elaborated on breaking the purpose of your code up into component parts. These components form the basis of multi-tier application programming. The advantage to this paradigm is that it reduces code necessary for customizations and allows a great deal of re-usability. To explain this further let's imagine you now want to display your news in another location of your website, or maybe just in another website on your server, rather than rewrite all the code to conform to some output format, you could just create a new render component. Then in the module declaration you would use the new render component instead of the original. In this manner your code hasn't changed per se, but you've provided a new "skin" for your news. This concept becomes highly popular when applied to applications you wish to market. For instance perhaps you want to create a bulletin board system, but everyone these days seems to want to store their data in a custom fashion. Some like XML, some like SQL, and some are already using a prehistoric flat-file system. Rather than create many different instances of your bulletin board framework, you can just provide different instances of the data component, or perhaps the logic component (these can often be combined to a single tier -- it all depends on how much separation you want).