Induction Model-View-Controller Overview
Induction advocates the use of the Model-View-Controller (MVC) paradigm to web application development. Following is a brief summary of how Induction supports models, views and controllers. In Induction the important types of classes you will write are controllers, views, models and model factories. A very simple application may only use controllers, but most applications will use controllers, views and models and very likely one or more model factories.
How Controllers Work
- A controller is activated in response to an HTTP request (the controller resolver maps HTTP requests to controllers)
- A controller is a class which implements the Controller marker interface (the Controller interface just marks a class as a controller, the interface does not enforce any methods)
- Induction dispatchs all requests to a single instance of a controller, therefore controller implementations are expected to be thread-safe.
- A model object or an environment object (such as the Request, Response or Form) is accessible in a controller by simply declaring a parameter of the model object's type in the controller's respective method (this is basically dependency injection)
- A controller is expected to have a method for each logical application task it performs. In other words a controller author has complete freedom with the method names. This is not a framework where you are forced to implement a handler method that makes no sense to your application.
- Let's take a quick peek at how a URL get mapped to controller. This URL to controller mapping scheme is entirely customizable. For purposes of illustration let's explore a typical scenario:
- Consider a Tomcat instance where the Induction dispatcher servlet is mapped to the root context. Now consider Tomcat receiving a request via the URL like yoursite.com/counter.increment.action, Induction is capable of mapping this URL to a controller class named: demoapp.counter_app.Counter and a method named increment
- Omitting the method (as in yoursite.com/counter.action) implies an assumed method name should be called, this method name is configured as handler by default, and can be changed in the Induction configuration.
- The type of the return value of a controller is significant.
- If the controller returns an object implementing one of Induction's view interfaces (Template, Text, Image or ImageStream the object is processed as shown below:
- implements Template -> processes and returns the content of the specified template object to the client
- implements Text -> returns the text contents to the client
- implements Image -> returns the image contents to the client
- implements ImageStream -> returns the image contents to the client
- If the controller returns a type (i.e. a java.lang.Class object) and the type implements one of the Induction view interfaces ((Template, Text, Image or ImageStream) an instance of the type is created (with dependency injection and the newly created view object is dispatched as described above. A view type is typically returned in a controller as in return ViewClassName.class (NEW! since v1.2.0b)
- If the controller returns an instance of Induction's Redirect class then, the redirect is resolved using the redirect resolver and an HTTP redirect is sent to the client.
- If the controller returns an object implementing one of Induction's view interfaces (Template, Text, Image or ImageStream the object is processed as shown below:
How Views Work
- A view may be activated as follows:
- In response to an HTTP request (the view resolver maps an HTTP request to view) (NEW! since v1.2.0b)
- In response to a value returned by a controller
- Induction instantiates a view by calling its public constructor (the view class is expected to have a single public constructor). Induction injects values into any parameters declared by the view constructor.
- A view class is one that implements one of the following interfaces (based on the purpose of view):
- Template
- Image
- ImageStreamer
- Text
- A class, say C1, that implements the Template interface is processed via one of the integrated template engines.
- When processing the template the only data passed to the template is an instance of the class C1. C1 serves as the bean that documents precisely what data the associated template needs.
How Models Work
- Implements pure application logic, completely independent of views and controllers (and the Induction framework)
- A model is any user defined class
- A configurable factory may be provided for each model class
- If no factory is provided Induction expects the model class to have a single public constructor which is called to create an instance of the model. Induction injects values into any parameters declared by the model constructor.
- Declarative control of the lifecycle of each model class:
- Application a model object is created for the life of the application
- Session a model object is created for each browser session
- Request a model object is created for each controller invocation