With a recent project, I’ve been deep in the bowels of the XPages component tree and run-time, with some detailed debugging involved. This has brought a few things to my attention

Dialogs and Component Loading

I’ve been adding a component to an XPage and then using Java on page load to access it. But when I put the component in a Dialog, my code failed. The problem is that although the Dialog component is accessible, the components within it are not loaded into the component tree until the dialog is displayed. This makes complete sense and highlights a lot of the strengths of the lazy loading of the XPages runtime. It’s similar also to the Dynamic Content Control, which also lazy loads its contents. It took a lot of debugging to work out why things were failing, and a bit of a workaround to achieve what I needed. But it’s the kind of challenge I enjoy because it reinforces the strength of the learning I’ve done on understanding the effort.

Custom Controls and IDs

As part of that attempt to get a handle on the component, I set an ID on the Custom Control so I could use FacesUtil.getComponentFor(). This isn’t immediately accessible on the properties, but possible. However, it couldn’t find that component for some reason. But it could find a component within that Custom Control. Back to troubleshooting!

Once you’ve got a handle on a component, you can use getParent() to navigate up the component tree. What I found is that although I found the Custom Control level – the com.ibm.xsp.component.UIIncludeComposite – didn’t have an ID. That’s why I couldn’t access it.

Again, when thinking about it, this makes sense because the Custom Control is basically inserted at the relevant position in the component tree in a “fake component”. It can’t just insert the whole Custom Control, because events like beforePageLoad etc need extracting. So it doesn’t have an ID with which to retrieve the component. But by getting a handle on one of its children, it’s still possible to navigate up to the right level.

This bring me to another issue. With a Custom Control ID set, my onClientLoad event was not getting triggered. So the bottom line is, don’t add an ID on a Custom Control – there’s no point and it will cause problems.

Data and Computed Properties

This is something I’ve touched on before, in my sessions last year. But it’s something I hit again recently. I had a dominoDocument datasource, set to ignoreRequestParams and picking up some properties set in the beforePageLoad of the XPage. But it wasn’t picking them up, even though they were being set.

As I covered in my “Marty, You’re Not Thinking Fourth Dimensionally” session, if the dominoDocument datasource is attached to an XPage, its properties get set before beforePageLoad. That’s why it wasn’t picking up what I was setting later. The solution was simple – just move the dominoDocument datasource to a Panel.

Leave a Comment

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top