Add facilities to extend views with custom snippets

[fabianbuch]

Currently inter module communication is already possible in various ways at the Controller level as well as on the service layer. Transparent extension of views currently is not possible. To enable real slicing of modules we need to come up with a decent solution for this. Let's outline the requirements and ideas regarding this:

h3. Declaration of view extension points

It shall be possible to declare view extension points inside JSPs, so probably a custom tag will be needed. It could look something like this

The tag then has to collect all extension points and render them, in this case wrapper inside an unordered list.

h3. Declaration of view extensions inside Spring config

Extensions could be represented by a simple Spring bean, e.g.:

As the configuration is rather verbose, I'd like to propose a namespace element to simplyfy configuration:

Some notes on that: the actual view implementation can be hidden behind the standard Spring @View@ interface. In case of a view name configured we could resolve the actual view using the configured @ViewResolver@s, the @ajax@ attribute could return a view rendering to HTML that causes a client side AJAX request (probably by jQuery).

h3. Resolving mechanism

The JSP tag now has to resolve the view for all the @ViewExtension@s found. So it can either use the @View@ reference or resolve the reference to be rendered by using the @ViewResolver@s configured. It's probably a good idea if @ViewExtension@ implements @Ordered@ to allow determination of the order of the extensions to be rendered. Actual rendering should be solved by calling @render(..)@ on the @View@ interface.

Let me know what you think :)

[fabianbuch]

Comment of Marc Kannegiesser: First i think the needed effort is way larger than 8hrs. 16 at least.

Some points to consider:

Model->View

Preparators have to be known within the Controller, in my oppinion. This is the only way we can ensure that first all data is prepared (Model) and then rendered (View) and dont mix things up (leading to the view directly changing the model). I think its better that first all model-preparation is done and displayed later. Because of this one would have to annotate the extension-point-id to all methods that lead to a view that contains the corresponding extension-point Tag.

Recursion

Think about Extension-Views decorate Extension-Views and make sure it works :-)

Wrapper-Delimiter

I guess you want to use the attributes wrapper and delimiter to render more than one extension-view to an extension-point.

This is ok but often not enough, as my expirience from "an big and old businessframework" showed. Best would be to extend this by some sort of a "Layouter" instance that can be given to the tag. This could then do all the styling. Example-Layouterinterface:

or even


public interface ExtensionPointLayouter {
   String (?) beforeAll(int totalElements);
   String (?) afterAll(int totalElements);
   String (?) beforeElement(int currentElement, int totalElements);
   String (?) afterElement(int currentElement, int totalElements);
}

Using such an concept generic layouters could be written as ListLayouter, TableLayouter (allowing to define number of columns), etc...