Save work object details in embedded pages
A developer asks: A key task for my application is copying information from one deeply-nested page into seven other deeply-nested pages -- then assuring that each of the seven "to" pages is valid.
The "from" is a deeply-nested page in my work object, and in the end each of the 7 'to' pages must also be embedded into the work object.
What is the best-practice design pattern for this? By "best", I'm looking for a combination of ease of development and high performance.
OPTION 1 - Use embedded pages within the work object. This has the advantage that both the "from" and "to" pages can be navigated using SmartPrompts, without requiring the manual addition of Pages and Classes entries for these deeply-nested objects.
- Do the mapping to create the first "to" embedded page.
- Validate this embedded page.
- If OK, move on to the next embedded page.
- If not OK, then back out this "to" embedded page by doing a Property-Remove.
OPTION 1A . Do the mapping for all of the embedded pages.
- Validate the entire work object.
- If not OK, then back out all the "to" embedded pages by doing a Property-Remove.
OPTION 2 - Use Named Pages (requires manual addition of Pages & Classes entries for each branch of the deeply-nested "to" object.
- Create a named page for the first "to" page.
- Use Page-Validate to validate the named page.
- If valid, copy this page into the work object and continue with the remaining "to" pages.
Presuming you have to do such manipulations, you should try to make it so that you do as few of them as necessary. If you're going to have to back out, you'll want to be in a position to do that as soon as you know that you should, in order to minimize the amount of garbage that your process produces.
Following that logic, it's better to use Option 1 of validating as you go rather than Option 1A of validating them all in one fell swoop.
Creating a lot of nested structure that you don't really need, for the sole benefit of not having to type entries into the Pages & Classes tab at design time, is not a good or recommended tradeoff.
Published December 12, 2005 — Updated November 15, 2015