0
votes

We have an XPages application, with a lot of forms. Everything is dynamic, meaning that the form content comes from one or more form definition document in Notes (one could say we built our own 'designer' environment): fields are dynamic, tabs, lists, etc... Now, as it happens, we have this enormous form with over a hundred fields, many of them are drop-down, with lots of options that are also dynamic.

It works, but it's slow. When a drop-down field changes, it triggers a partial refresh with partial execute of the closest tab. But when we look at our logs, the partial execution affects the execution during the first phases. During rendering, our Java code recalculates the whole form and all the fields on all tabs. We already use a phase listener.

@53.604: APPLY_REQUEST_VALUES, starts with going through all fields (~1s), then continues with the fields on one tab only. Great so far.

@55.057: PROCESS_VALIDATIONS, tab only. Excellent.

@55.338: UPDATE_MODEL_VALUES, tab only. Swell.

@55.495: INVOKE_APPLICATION, tab only. Perfect.

@55.651: RENDER_RESPONSE, the whole form is processed.

@59.121: end of processing

My question: Can we add some shortcuts to our code, so it can skip the evaluation of tabs and fields that don't change?

For example, is it possible to find out using some built-in method or so whether XPages is doing a partial refresh, and of which element?

Thanks for your assistance.

2

2 Answers

1
votes

Tabbed tables don't work well on the web, and this is one of the reasons. I'd recommend refactoring so your app uses a "wizard-style" approach, where it's a single XPage with each tab on a custom control and only ever one custom control loaded. This requires changing your navigation to reload the page and using some backend method for identifying "drafts" (i.e. not all tabs visited and validated) and completed. But it also removes the risk of a user completing all tabs, submitting and the "save" request failing, which would mean they would lose everything they entered.

Other approaches that may have benefit are to use the the Dynamic Content Control to load one tab at a time (previously visited tabs would still be in the component tree though, but tabs not yet visited would not) or using execMode to restrict what the server processes. However, you need to ensure everything you need processed is within the execMode, so it may require some reorganisation of your page.

0
votes

I use commonly tabbed forms (Bootstrap) in my XPages and have not experienced performance complications to them. To me it seems either the computations you make in the background in combination with the amount of fields that form the bottleneck.

Have you uses the xpages toolbox to see how many back-end objects (databases, views, documents) you access with each partial refresh?