It's a very common design practice to have one section of your user interface be visible, or invisible, based on the values in another section. This helps minimize confusion of what should and should not be entered. Lets example a very simple, but representative, use case of this. We have a combo box above an edit box. When some values in the combo box are selected, the edit box should be visible, and when others are selected, it should be invisible.
Similarly we need to be able to set the visibility of the edit box. We can retrieve the component using getComponent() as above, and then fill in the setRendered() API. This will control if the edit box is rendered to HTML or not. The complete code for this is here:
var combo:javax.faces.component.UIComponent = getComponent("comboBox1");
var comboVal = combo.getValue();
var edit:javax.faces.component.UIComponent = getComponent("inputText1");
if (comboVal == "Other")
By default when the onChange function completes, the entire page is re-rendered. This gives us the effect we are looking for, but is potentially slow and disturbing. It would be more efficient to just refresh the edit box itself. There is an option on the event that lets us choose to only partially refresh the screen. However if we choose that and specify the ID of the edit box, it does work quite as expected. When we tell the edit box not to render itself, it is not present at all. So when we try to do a partial refresh there is nothing there to refresh!
The solution to this is to first place a Panel control on your page. Give it a memorable ID. Then put the edit box control into the panel control. Change the event logic to refresh the ID of the panel. The panel is always present. We are not changing if the panel is rendered or not. So it is safe to refresh based on that ID. Within the panel, the edit box may be rendered or not, depending on our logic. When the panel is refreshed, the edit box displays or does not display based on this.
This has illustrated some techniques for dynamically displaying regions of the screen on your XPage. In general the "push" model has been followed. The changing control is responsible for changing the settings in another control. One could equally implement a "pull" model. Where when the dependent control is rendered it queries the setting control for its value. You should evaluate your use case and determine which is the best logic for your application.
The above example has controlled visibility using the rendered attribute of a control. Another option would be to use the loaded property. The loaded property is only evaluated on initial page load and when context.reload() is called. This makes it more appropriate for coarser grained visibility settings, such as if a user with a role should see a section, or if the document in a workflow should render a section.
One or the other can be applied to give your application dynamic responses to user input.
For a wider discussion of making things selectively visible and a comparison between the client approach and the server approach see the article "Selective Visibility on XPages