Conditional Page Rendering in Java Web Frameworks - Best Practices?
This is a post, that requires your input 
I want to harvest the information in your brains, on how your favourite web framework is best at not cluttering the view pages, when you need to show them differently for each user or state of the application.
Definition: Conditional Views
I have no better name, than “conditional views”. Often, when I create web applications, the views (pages) of the application, needs conditional expressions, which makes them show up differently, typically dependent on the abilities of the current user. This could be as simple as checking some role, but also “complex” as in checking some application domain logic specific conditions, to determine if an input field should be editable or not.
In simple JSP, it is something in the lines of this:
<% if (someexpr) { %>
<input name="onlyIfSomeExpr" type="text"/>
<% } %>and of course this can be put a little more nice, by using JSTL or tags like it, as this shows:
<c:if test="${someExpr}">
<input name="onlyIfSomeExpr" type="text"/>
</c:if>
When It Becomes Messy
The above examples might not seem as such a big deal, but when the if-then-else parts of a view becomes many and in multiple levels, we quickly loose overview of when form tags close etc. It can quickly become really messy.
How To Do It Then?
Is there any good way, to keep the views simple, as the complexity in the conditional rendering of pages go up? I have tried many web frameworks over the years, but never found one, where this was not a problem. Tapestry has nice POJO-based, component framework, but still, @Conditional shows up as if-else in the templates. Grails/Rails have views that are basically JSP, but with other syntax. Etc.
Is there a great library, to help me solve this problem? Maybe some filter to post-process output? But still, I would have to markup the produced output somehow, to make the filter be able to do its work. I do not know. Do you?
Hi Per,
I’am not aware of any library out there, but I would like to share some experience from a project I have been working on. Well the question in action is - how do we avoid cluttering the view pages with all the conditional expressions needed by all applications?
This solution builds on the principle that all form fields in your view pages should have an accosiated DisplayAttribute in a backing code class. The value of the DisplayAttribute should determine if the current field should be read-only, hidden, disabled and so on…
When the page renders each field have some logic which can draw the html e.g. a taglib or a component. This logic should read the display attribute of the field and act upon it.
This gives you a clean JSP page where all the dynamic about the different conditions a determined by the value of the DisplayAttribute and the logic associated to act upon it.
When to update/change the DisplayAttribute? Well, this could be when the page is about to render. Here you need at method to hook into where all the view business logic could reside and change the DisplayAttribute accordingly. In Tapestry we had some possibilities with the PageBeginRenderListener interface.
On my project this was implemented with the Struts framework where every field on the Struts ActionForm had a DisplayAttribute. Of cource you need more code in your form class, but it would otherwise have been on the JSP page. It was possible to override a specific method for every form where view business logic could be coded and all the taglibs on the JSP page was implemented to adhere to the DisplayAttribute.
Well this was one way of doing it and maybe not an easy one because you need to have a DisplayAttribute for all fields and the logic to draw the fields needs the value of the DisplayAttribute and should act accordingly. All of this should of course be supported by a web framework
This can give you a better overview of the JSP, but you can also loose the overview since all the logic about when to display what is separated away.
What do you think? To cumbersome or?
Regards Claus
May 17th, 2008 at 21:02Well, in Wicket the view stays simple all the time:
In your Java code you can do anything you want:
add(new TextField(”onlyIfSomeExpr”) {
May 17th, 2008 at 21:23public boolean isVisible() {
// someExpr
}
});
The view (this time escaped):
<input type=”text” wicket:id=”onlyIfSomeExpr”/>
May 17th, 2008 at 21:25@Claus:
Interesting idea with a DisplayAttribute, though, as you mention, there gotta be a lot more extra work in this solution. Maybe something that lends itself better to code-generation. I was wondering: If running on Java5, one could annotate properties on the form-bean, to mark them visibile, hidden, disabled, etc. It would remove the need for extra methods. Just a thought.
I would fear this solution to not be able to cope with all the special cases, that large applications with complex views need. Like rendering the same property totally different, in case of true or false on some domain-specific expression (aka: Not just a role check). But I don’t know, maybe it could be put into the tag-rendering stuff you mention.
Thanks for the input.
May 17th, 2008 at 22:03@svenmeier: Interesting. But that is *very* simple example (setting hidden true or false on an input field). How about rendering totally different, in case of true or false. Like this:
Note: I am just dreaming up this example as I go, but how would the view (and backing bean) look like in wicket, to support this?
May 17th, 2008 at 22:09In Wicket, you have 2 options then - Fragments / Panels.
You can use Panel-s if the markup is reusable across several projects/ pages and fragments if you don’t see it being used beyond that page for example.
So you would have a panel (TextFieldPanel) that just encapsulates a input text field.
And you will have another panel (AnotherPanel) that will encapsulate the image and the javascript stuff.
And in the page that conditionally renders them , you would now have a “place holder” like so -
and in the backing page, you can have something like this -
if(someExpr){
page.add(new TextFieldPanel(”conditional”));
}else{
page.add(new AnotherPanel(”conditional”));
}
In Wicket, the view is pretty much dumbed out - it is used just for specifying markup/layout and as a result is very clean.
May 19th, 2008 at 19:24Wicket also has something called an ‘enclosure’ that you could choose to use. This is a convenience feature designed for those situations where the visibility of a whole section of HTML can be controlled by a single associated component.
This is explained in detail here:
http://www.systemmobile.com/?page_id=253
June 1st, 2008 at 19:30i landed up on this page looking for something similar.
I was looking for some kind of rule engine that would serve up the conditional parts of the code. And rules would have priority to determine from the best to the least fit one. Googling for JSP + rule engine or JSP + drools is not helping so much!
August 14th, 2008 at 19:14