c:if test=”${user.loggedIn && user.bookedProducts && user.hasPaid}”

is easier to change, lets say you want to show something more if user.bookedProducts, in this example is easy and in your version you need to add another business method/field for that.

I think great example of UI logic are reports, for example FOP, you pass xml data to fop and it creates report using XPath. When reports need to be changed, for example you want to count how many products is ordered you just execute XPath query and NOT add another xml field with count result. This way there really is UI logic in your example UI logic is … not existing, you have just business logic.
I also worked with reports on production and using UI logic i was able to change them, in your example that wouldn’t be possible because you need to also change your business logic for that.

I don’t think you should worry about things being reused, but worry about how things might change in time.

Agree with you completely.

Thanks
Prashant

You’re way doesn’t provide a solution for the distributed nature of the mapping. With your example you still distribute the decision of showMenu over several components possibly.

I could use a JSTL custom tag just like you use a wicket component. But the still: Put the decision of showMenu in the component or put it in an adaption layer. What if you have several widget which should be shown depending on a condition?

With JSP the code is in the c:if, with wicket it’s in here.

isVisible = hasPrice();

public boolean isVisible() {
return hasPrice();
}

But this mapping has to be written down somewhere. That’s my point. Either explicit or implicit. And I vote im most – but the simpliest cases – for explicit.