The XPages Blog

I just got out of the very enlightening AD109 session on XPages performance and pigeonholed one of the speakers, Thomas McGuckin from the XPage development team.  There are a couple of things that I'd been scratching my head about that he helped clear up.

Let's say you have 2 custom controls on an XPage, A and B.  In custom control A, you have a field.  In custom control B, you have a computed field that has the server-side code:

getComponent('IDofFieldOnCustomControlA').getValue();

The computed Field will never get set because it can't "SEE" the field in custom control A.  Why is this, and how do you get around it?

Think of the custom control as a container.  For custom control B, when getComponent is called, it operates within the context of that custom control.  Other custom controls are basically black boxes that it can't see into.  While that may sound unusual at first, it actually makes sense.  What if that custom control is inside a repeat control?  There's no way to guarantee the uniqueness of the id of that field.

Given that, it's not really appropriate to even try to phrase the approach in that way.  Instead, it was suggested to do 1 of three things.  For the field where the value is being set:

a.  put it in a scoped variable

b.  in Control B, access getDocument and grab the value from their (relevant where the control you're trying to get is for some data point).

c.  Create a custom property in Custom Control A, and set the value of the property from the control.  Custom Control B can see Custom Control A and access it's properties...it just can't see inside it.

Some worthwhile solutions to what was becoming a common problem for me.  However, while these are good solutions for accessing 'data', what if you really want to get a handle to a panel in the other custom control because you need to hide it for example.  None of these solutions really addresses that kind of requirement.

I'm sure someone brilliant here has a solution for this too.

-Lance