Social Icons

twitterfacebookgoogle pluslinkedinrss feedemail


Sunday, October 21, 2012

Choosing between xpages controls and plain html elements

It is better to use plain HTML elements as far as possible inside your xpages/custom control markup. For example, if you don't need to do a partial refresh of a DIV or you don't need to work with that DIV on the server side at all, you better use the plain div instead of the xp:div. The same is true with any other html elements. This will reduce the number of component objects the JSF tree has to maintain on the server and understandably will improve the performance. (Before JSF 1.2 it was not recommended to mix in JSF and plain html tags)

Having said that, how do you know if a div is going to be accessed on the server side right when you design the page!! What I do is to start with plain html elements for which it is less likely to have an associated server side code (like partial refresh/onclick event) and then convert it to a xpages tag later when I discover it needs some server side handling.

There are some instances where you need to do some server side computing while rendering the plain html code to the browser. For instance, if I need to render a plain html div tag (because I don't have any server side code attached to it) with some attributes computed based on some business logic. You can do something like the following.

 div class="row" me="customer" myid="#{javascript:entryCustomer.getKey()}" parid="#{javascript:entryCompany.getKey()}">  
   <!-- some other controls or contents go here -->  

I am sure I tried something like this in version 8.5.1 and it didn't like it. Since then I was thinking that a server side evaluation won't work other than on a standard xpage control. Just out of curiosity I tried it today, and it works. Very cool, now I can replace a lot of xpages controls with plain html controls.


  1. Are there reasons why Designer does not visualize divs (and some other html tags) ?

  2. I am not sure if using plain HTML will bring you the performance boost you are expecting. Plain HTML will result in UIPassThroughText components and are still Part of the JSF component tree.

    1. Sven is correct: passthru tags are still component instances and part of the tree. But you're also right in saying that they're more performant than namespaced controls. The reason is that, because they can't store data or have events, they're essentially ignored during all JSF phases except the first ("restore_view") and the last ("render_response"). So there's definitely an incremental performance gain. However, this tends to be less noticeable than the other ways of maximizing performance: using $ instead of # whenever possible in your EL; using plain EL instead of SSJS; and properly managing scope content to ensure that expensive expressions are only evaluated as needed and flushed from memory as soon as possible.

    2. Good to know that there is equivalent UIPassThroughText for those vanilla html tags, not certain but I am thinking those stateless components will be needed in the tree to re-generate the part of the html page after a partial refresh later. From the research I did, it looks like this plain vanilla html approach will make the xpages applications more scalable and won't tax much on the server resources. Thanks Tim & Sven for your excellent explanation as always. I am a regular reader of your blogs.

      @quintiexxx: I was thinking the plain html div's do visualize like xp:div. But I may be wrong.