What's the point of the xpages xp:include tags if the data with in it won't save from the calling xsp?

0
votes

The one-ui app I'm building has a few forms each with a common custom control for the Save, Save and Close, Edit, Cancel, Delete buttons. These forms are built with several Tabbed Panels, which were created as separate xpages. These pages are called by main xpage using the include xp tag.

<xp:include pageName="sub_tab_6.xsp" id=include6"></xp:include>

This technique does a fine job of showing data and permitting data input, however any data input or edits are lost even if the Save button is clicked. Those fields on the main calling xpage get saved, however those data on included xpages (and those on form parts placed in Custom Controls , I tried that too) don't get saved.

I tried, for fun, putting a separate Save button on the sub-xpage, and this caused havoc with some fields going into Read Mode and Save Conflicts began to appear, of course.

Short of merging my sub-xpages into the main xpage, is there a better way of form design?

(Windows Client: Release 9.0.1 FP9 (Server: FP10, Longhorn64 6.1)

1
xpagesxpages-extlibxsp
Anyone? Bueller? - Leon Matthys
It depends on what is in the included page -- is there a DominoDocument defined for each page? If so, that can give you replication conflicts. If only one document is wanted, then make sure only one is defined between the both of them. I would suggest building a Custom Control rather than including another page -- this is similar to a 'sub-form' in a Notes form. - teleman
Please include some boilerplate code including datasource definition and what is coded on the buttons. There's very little to go on. But as teleman says, I'm not convinced this is a standard use case for xp:include - Paul Stephen Withers
I've never found a need to use it. It's unclear why separate XPages have been created as opposed to, for instance, creating a Custom Control which is added to an XPage wth tabbed panels and a standalone XPage. It's also unclear where the datasource(s?) are defined, which could have a big impact on what gets saved. - Paul Stephen Withers
One possible reason for using includes over custom controls is for emulating computed subforms. If you require specific custom controls depending on the content of the main page, it can be messy to add all possible custom controls and control all the rendered attributes. A computed include page is easier. - Tom Van Aken

1 Answers

1
votes

If you use a custom control or include page, don't define your data source on it, but use the datasource name of your Xpage. For example: if you're datasource on the xpage is called document1; you can use document1 in your custom control or include, even if it is not defined there.

This will work fine if the datasource name is the same on all Xpages where you use the include or custom control. If you want a more dynamic approach, you can pass the datasource as a property of the custom control (and access it through compositeData). More details on this technique is answered here How to send a document data souce to a custom control in XPages?.