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 -->
</div>
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.
Are there reasons why Designer does not visualize divs (and some other html tags) ?
ReplyDeleteI 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.
ReplyDeleteSven 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.
DeleteGood 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.
Delete@quintiexxx: I was thinking the plain html div's do visualize like xp:div. But I may be wrong.