-
Notifications
You must be signed in to change notification settings - Fork 1
View
As a result of any URL call handling a model is returned to be viewed in the client browser. The templating layer of Tangram doesn't care where the instances to be rendered really stem from.
In addition to this model which is essential, a view name may be issued by the URL handling parts of the application. This view name might be just "null", but even this describes a certain view: the default view.
So any rendering of pages, images, and the like is triggered by a (mode, view) tuple (Like the Springframework calls it ModelAndView).
The difference between Tangram and some other rendering frameworks is the way the Template lookup takes place. Tangram interprets the view name a an object oriented viewing method name. Thus the template called depends on the class of the model.
Let us have a look at an example which still ignores the viewing technology used (e.g. JSP or Apache Velocity).
The handling of URL /u returns an instance a of class A and the information that a view with name v should be used for that instance.
To fully understand what Tangram does with this information, you additionally have to know, that class A is a subclass of class B, and that class A implements interface I while class B implements interface N.
The very essence of what happens now, is that Tangram tries to call the viewing method v for the instance a. The following descriptions just add complexity with the very details, special cases and conflict resolution.
So Tangram tries to find
- a view named v at class A
- a view named v at class B
- a view named v at interface I
- a view named v at interface N
if a view implementation is found at any of these steps, the process is stopped and that view is rendered with the result being sent to the client.
The first two steps of the resolution just mean climbing up the object oriented hierarchy. The latter two steps don't sound familiar in the Java world, since interfaces cannot contain implementations (as of Java 7). Together with the way templates are implemented, this cannot be true for Tangram. While the interfaces in Java still may not contain any implementing codes, it is possible to add a template as a viewing method to this interface (e.g. by placing a JSP in the right folder with the right name - see below). As a result we have to deal with this and took the decision to first climb up the hierarchy and then take any interface of the classes along the way into account. So the implemented interfaces of class A still have precedence over the interfaces implemented by B, but the hierarchy of classes has precedence over the interfaces in general.
As the last layer for the template resolution, there may be more the one set of templates in the system. Tangram comes with JSP based templating from files or resources and an Apache Velocity based templating where the templates are stored in data storage backed instances.
To avoid the discussion if we should use MVC, MVP, MVVM or anything else which includes views and models, we - of course - still stick to the viewing of some model but don't rely on a specific source of the model and the model may in fact consist of several related instances of arbitrary classes.
The two main use cases are the viewing of a data storage backend object and a fully dynamically generated object. The database backed objects are - more or less - the equivalent of a content based "static" HTML page, while the dynamically rendered objects resemble responses to user requests for some action.
In both case - but at least in the former - it is a common case that just passing the model to the view layer is not enough. A special model tailored for the intended view must be created.
To avoid the need of a view-model layer technically inserted into the system for any HTTP call which would then be present in even the most simple cases, the model extension is a dynamic feature in tangram.
Any class used for rendering may have associated classes which use the former as a delegate and are - optionally - dependent on the current request. Tangram calls these small extensions "Shims" - just dependent on the delegate - and "ViewShims" - also depending on the request.
Tangram automatically discoveres the associated Shim and ViewShim classes from the groovy classes in the repository and creates instances as necessary. The instances are added to the scope of the template used for viewing and may be access by their name. This name is returned by the Shim or ViewShim implementation and defaults to the implementation base class name without the package.
For static templates packaged together with the application, Tangram uses Java Server Pages (JSP).
JSPs as views for the object oriented templating must be placed in special subdirectories
of the WEB-INF/view/jsp base folder and have certain names to be recognized as
views with for a given class and view name.
The subdirectory must be named like the Java package of the class the view is intended for. You don't have to present this as a structure of subdirectories like for Java codes.
The JSP template name is the classes base name with the view name separated with a ..
The .viewname is omitted for the default view of a class.
If Templates are part of your dynamic codes, they need to be placed in code resources in the repository.
Any code resource with mime type text/html or text/xml is interpreted as a
potential Apache Velocity template. The Annotation should be of the for
package.ClassName.viewname where the .viewname part is optional to mark default
views for a certain class.
Available Apache Velocity views have precedence over Java Server Pages with an otherwise identical setup.