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!

This is explained in detail here:

http://www.systemmobile.com/?page_id=253

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.

<% if (someExpr) { %>
  <input type="text"..../>
  <p>and a lot of other stuff here</p>
<% } else { %>
  <img src=.../>
  and then maybe a bunch of javascript here,
  just to make the example a bit more interesting
<% } end { %>

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?

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.

<input type=”text” wicket:id=”onlyIfSomeExpr”/>

In your Java code you can do anything you want:

add(new TextField(”onlyIfSomeExpr”) {
public boolean isVisible() {
// someExpr
}
});

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