Inspect Component Properties using Component Binding

Inspired by Paul Withers recent component binding post, I discovered¬†another use for component binding whilst I was preparing for my upcoming presentation ‘Anatomy of a UI Control’ this Thursday at AUSLUG.

In my presentation I demonstrate how to determine a component’s Component Family and it’s Renderer Type¬†which are both essential to determine which renderer is selected for the component by XPages.

It is extremely similar purpose to a technique that was previously demonstrated by the late Tim Tripcony on his blog. Tim demonstrated how to determine a component’s StyleKitFamily, which is an important setting when applying theme properties.

All I have done is rejig the concept to use component binding to link the component to the computed values which output the properties.

In this example I am inspecting the settings of the widget Container, however if you want to inspect a different component, then remove the widgetcontainer, replace it with whatever component you want to inspect, and make sure the ‘binding’ property is set the same as it was with the widgetcontainer.

When the Bootstrap theme is applied to the application, the properties are as follows:


Obviously with different themes applied you might get different renderer types for the same component.

I have added it as an XSnippet

At the end of the day, this is not really groundbreaking stuff! You could achieve the same result beforehand with a few SSJS computed values as follows:

However if you are weird like me and prefer to use EL because it looks nicer in the markup, then using the Component Binding might be an option for you!


You may also like...

8 Responses

  1. Paul Withers says:

    Worth emphasising here is using requestScope for the binding. The natural inclination is viewScope, because it needs to be accessible for the life of the page. But you’re right that requestScope is best, because I guess nothing is stored in the requestScope except a pointer to the component. And because the component tree is reloaded for each request, the binding will get reprocessed and the pointer added to reqeustScope again. It’s similar to variables within Panels or Repeats, because they too get added to requestScope (temporarily).

    • camerongregor says:

      Yes exactly! I have previously run into the problem that if you use viewScope, the UIComponent is not serializable.
      This is not a problem with in-memory view persistence, but IS a problem if disk persistence is in place and throws the ‘not serializable’ error when it tries to serialize to disk.
      If you bind it to a managed bean in viewScope you can mark the ‘bound’ field transient and it won’t attempt to serialize it. I think you covered that in one of your posts?

  2. It is even shorter to use the local EL scope with binding=”#{myComponent}”. Then you can access it with value=”#{myComponent.styleKitFamily}”.

  3. Csaba Kiss says:

    Interesting stuff. I did not even know that the Widget Container existed. Has anyone wrote about them?

    • camerongregor says:

      Hi Csaba, I haven’t seen anyone blog about it but they are described in the XPages extension library book, and also there are some examples in the Extension Library Demo Database.
      They are quite handy to use in left/right side panels

  1. September 19, 2016

    […] component family can be found with a little debugging, we can choose whatever name we want for renderer-type, and we know the java class because we just […]

Leave a Reply

Your email address will not be published. Required fields are marked *