What's the View?
The View is the MVC layer in charge of displaying the information to the client.
The benefit of using the View is that we abstract how the information is presented to the client, being able to modify our application's look and feel without affecting to any other layer.
Unlike other traditional request-driven MVC web frameworks, Lion uses a component-based approach that eases the rich web clients development.
This approach includes:
- A set of APIs for representing user interface components and managing their states, handling events and input validation, converting values and supporting internationalization.
- A default set of GUI components.
- An event management system.
- A server to client component binding.
Because doing a web 2.0 application continues being a hard task nowadays, component based views eases this task by allowing the reuse of interface functionalities encapsulated in components.
What's a component based view
Lion component model is similar to the AWT GUI component model. It has events and properties just like the Swing component model. It also has containers that contain components, and that also are components that can be contained by other containers.
In that sense, the Lion component model is divorced from traditionals view layers. Lion view allows not just to define the interface look and feel but dyncamic behaviors.
Examples of Lion components include calendar and rich HTML input components. You may never have time to write such components, but what if they already exists?
The component model lowers the barrier to entry to add more functionality to Web applications by making a commodity of common functionality.
Executing the View
The piece of Lion framework that has the last word about which view to execute for each action is the action controller.
The action controller creates and returns a __ModelAndView instance each time it executes an action (or null for his own purposes).
Once the action controller returns a __ModelAndView, the __ViewResolver will determine which is the most appropriate view to use to render the user interface based on the information provided by the __ModelAndView instance.
The __ModelAndView can provide the exact view to be executed.
Otherwise, the __ViewResolver will resolve a view according to the specification described in the views.xml configuration file.
i.e.
<?xml version = "1.0" standalone="yes"?>
<configuration>
<view-definitions>
<view code="*" class="__SmartyView">
<property name="template" value="*.tpl"/>
<property name="eventHandlerClass" value="*EventHandler"/>
</view>
</view-definitions>
</configuration>
In this example, we are declaring the __SmartyView class for any view code, which it means that if the __ModelAndView does not provide a view, the __ViewResolver will determine the __SmartyView as the view to be executed.
