Rendered vs. Loaded

Monday, May 26, 2014 5:38 PM UTC

Today I ran into a strange thing which was - after some reconsideration - not that strange at all.

Given is an application with 2 XPages and 2 Custom Controls. Both Custom Controls bind a JS lib each (control1 binds lib1.js and control2 binds lib2.js). If you compute the "appearance" of both controls you probably would do this using the "rendered" property, just like this:

 

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xc="http://www.ibm.com/xsp/custom">
<xc:control1>
<xc:this.rendered><![CDATA[#{javascript:return context.getUrlParameter("id").equals("1")}]]></xc:this.rendered>
</xc:control1>
<xc:control2>
<xc:this.rendered><![CDATA[#{javascript:return context.getUrlParameter("id").equals("2")}]]></xc:this.rendered>
</xc:control2>
</xp:view>

 

In this case each control is visible if an URL parameter is set so it's specific value. But that's not important here.

What you will get when opening the page (even without any parameter) is this:

Got it? No matter of how you define the URL parameter, no matter if the content of the controls is visible or not (btw the visibility works as intended) - both resources are loaded in the page. That might not be a problem then? Ohhh, it can be a problem! Imagine both libs containing special code (and maybe equally named methods in there) for each control. You will run into a hassle.

I am not sure but this might have it's origin in the phases each XPage is running through. The renderer phase is run after the loaded phase, because if you use the "loaded" property instead everything works fine:

 

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core" xmlns:xc="http://www.ibm.com/xsp/custom">
<xc:control1>
<xc:this.loaded><![CDATA[${javascript:return context.getUrlParameter("id").equals("1")}]]></xc:this.loaded>
</xc:control1>
<xc:control2>
<xc:this.loaded><![CDATA[${javascript:return context.getUrlParameter("id").equals("2")}]]></xc:this.loaded>
</xc:control2>
</xp:view>

 

Notice the dynamic computation of the properties with $ instead of #. You are not allowed to use # in that context, but it's ok.

Now the JS resources are also computed depending on the visibility of the control itself:

This was new to me so maybe you'll find that helpful.

Update

Brad Balassaitis posted a similar article regarding resources - but used in a theme. It's also a good read!





Latest comments to this post

Oliver Busse wrote on 28.05.2014, 19:15

Tony, thank you very much for that detailed comment! I really appreciate it!

Though I'm now able to read those chapters of the Mastering XPages book I always felt more convenient using the "loaded" property to compute the usage of a component (e.g. a custom control). This was just a feeling and was caused by the simple translation of the words "loaded" and "rendered". What is not loaded doesn't bother me (and the system) at all. But your statement confirms that my assumption was right regarding the phases of the JSF/XSP lifecycle.

So I might be right to thank you and your team who created the XSP above the JSF layer for adding the "loaded" property on top Smile

 Link to this comment
Tony McGuckin, IBM wrote on 28.05.2014, 13:24

Hi Oliver,

Both properties are special with regard to how XPages processes them relative to the XPages Request Processing Lifecycle.  I should also add that regular JavaServer Faces does not provide a 'loaded' property, only the 'rendered' property.  So 'loaded' is an XPages enhancement over and above regular JSF, and for very good reasons.

Without drilling into all the detail here, it comes down to the way an XPage component tree is managed in server-side memory.  Basically, any component can be either loaded or not (loaded being the default) and thereafter "visibility" can be controlled using the 'rendered' property. If a component is loaded but not rendered, then this means it is still resident in the component tree but simply no HTML has been emitted. On the other hand, if a component is not loaded, then it simply doesn't exist at all within the component tree - therefore 'rendered' is obsolete in this case.

Chapter 19 and 20 on Advanced Performance Topics in the new Mastering XPages (Second Edition) book contains full details on the myths of loaded vs. rendered and the XPages Request Processing Lifecycle along with how to profile your application.  I encourage reading of this material to gain a full understanding of what is actually happening here from a technical standpoint but also to avoid any sub-optimal code / performance issues when programming with these special properties.

If you want to perform "hideWhen" logic, then I suggest not using rendered in the normal case... the Dynamic Content control and a deeper understanding of loaded vs rendered combinations will make your applications highly performant and scalable.  All of this is described in Mastering XPages (Second Edition).

If you don't have a copy of the book yet then in the meantime you can get introductory information about the XPages Request Processing Lifecycle / rendered vs loaded / profiling etc. from the XPages Masterclass video series on OpenNTF.org.

Kind regards,

Tony

 Link to this comment

Leave a comment right here