Concept

The original motivation behind starting the InterJinn project was to create a well integrated framework that would allow for the easy creation of Web applications while retaining a high degree of flexibility and scalability. These mandates have been met at every level; moreover, since the InterJinn framework itself does not require any exceptional circumstances other than loading the project configuration, you can choose to use it for all of your application needs, or only where you please -- It should happily mix with any other framework or even HTML embedded PHP. The following sections describe how the main goals of the InterJinn framework have been met:

Integration

To meet the first objective of a well integrated framework, InterJinn defines services for the most common aspects of any web application. These include session management, profile management (profiles are like session data but permanent), and database access. Furthermore a tiered and hierarchical property system was designed to provide arms length definition of component aspects and to also provide a transparent layer to some of the aforementioned services. In this manner accessing a session variable can be as simple as the following:

$this->isAdminUser = true;

This may appear trivial at first, but considering the binding of the session data occurs in the background, allows for a default value, and is saved back to the users server side session description without any other developer interaction, it is a testament to the ease of use of the property system.

Flexibility

All services and components extend a common base class. By doing so all services are retrieved in a common way and are de-coupled from other services even where a strong affinity might exist. This has the powerful advantage of making it possible to swap in custom services that meet the original interface and provide new or enhanced functionality. While this seems like it might be difficult, doing so is as simple as extending a core service class and updating the service registration. Alternatively a replacement service could be designed from scratch. An example of this kind of swappable functionality is exemplified by the most of the default core services which come with both a database storage system and a filesystem storage mechanism when applicable. Since the interface is identical, the filesystem storage mechanism can be swapped in to replace the database mechanism (this isn't entirely correct, to ease configuration these core services do an internal switch based on the configuration value but originally it was done using the swap mechanism). In case you're not yet convinced, a second swappable Database Service that wraps the PEAR:DB library, can already be configured in place of the default MySQL layer. The default database layer works via the default PHP MySQL library, and so it is expected that alternative database services will be created to meet the needs of systems using PostgreSQL, Oracle, or whatever is available. In this way, InterJinn embraces other solutions, open source or otherwise, while maintaining its own well defined method of operation.

To further extoll the flexibility of the system, components are generally atomic (as in purpose not as in locking mechanisms) and can be bound together to form modules on the fly at run-time. Moreover, as mentioned earlier a property system exists to configure components at arms length. The purpose of the binding is like the choice of ingredients when making a pie. Generally you might have basic ingredients, but some of these are swappable. For instance you might have a "crust" component, and a "filling" component. Now let's imagine in one web page your filling is blueberry, wouldn't it be nice if you could make a cherry pie on another page by just changing the filler and without needing to make any special adaptations. This is what the binding does, it will bind the cherry filling to the crust at the page level as part of the module declaration. Moreover given the property system, the size of the pie can be controlled without changing the component's code. This kind of functionality is in contrast to conventional object oriented philosophies that essentially require you to declare the binding in the recipe rather than when the pie is being made. Albeit many systems use some kind of arms length configuration, you will find that InterJinn goes one step further and implements a hierarchical and inheritable property system which makes extending default configurations simplistic.

Scalability

If you read the above section on flexibility then you are probably already able to imagine how InterJinn provides a scalable foundation. As needs change or increase in complexity, InterJinn allows for the definition of custom services. Services essentially package libraries of well defined functionality for use by other services or components. A good example is the FormJinn engine. This describes a form engine service whereby developers can make use of a simple yet powerful API for declaring, configuring, and validating form data. Furthermore, if a service is never requested, then its code is never loaded. This makes it possible to draw functionality from a massive set of services without incurring a processing hit other than the registration of the service (a few lines of code). There are many services packaged by default with InterJinn, and it is expected that more will be added as needs arise and as the development community makes available third-party services and components.