Multi - Object Design pages

[CharlesHarder]

Hello,

When building an object using the multi-object design approach would it be recommended to split each field being read into their own page?  Using the example in the Object Design Guide (5.2) the "Get Account Details", instead of having one page that outputs all the fields, to have 13 individual pages to output one 1 field.

Any insight would be helpful

[John__Carter]

That might be going a bit too granular, although I've seen it done. Going so small could have an effect on delivery (more pages to build and test), maintainability (many pages to change), process complexity (many more Actions) and maybe even size (more XML to be transported and stored).

There's no exact way to do it, although the general ratio is one object per application screen, with object pages to 'navigate to', 'navigate from', 'read from', 'write to', and 'commit changes'. The main thing is to avoid single mega objects that will grow to become a burden you'll regret creating. I know this from painful experience!

To some extent you'll have to learn as you go, and as your experience grows you'll arrive at a scaling that works for you.

------------------------------
John Carter
Professional Services
Blue Prism
------------------------------

[david.l.morris]

I'm going to blabber for a paragraph and then give a suggestion in the next paragraph. =) I agree with John's comments, and I think specifically maintainability and process complexity would be negatively impacted by having a single page for each piece of data retrieved from a page. The way I think of it is that I try to output data from an action where the data items would form a cohesive unit of information (a dataset). For example, if the screen has details about one account or has a list of accounts with basic data about each or something like that, it makes sense to output all that from a single page. I think it depends on the kind of data and how you intend to use it in processes that will affect whether it is output as a collection of 13 fields or as 13 separate outputs. Personally I cringe every time I have a page output 13 things because that's not normal in programming. But if you think of it as though the outputs are actually just one big item with 13 fields then it's not that weird for it to all be coming from a single page/action. You wouldn't have separate actions to output row 1 and row 2 of a collection, so no need to have separate actions to output column 1 and column 2 of a dataset. That's how I think of it anyways.

So, my suggestion... If you are interested in trying out your idea and your organization supports you in it, then you could try a kind of middle ground to begin with, one that would not negatively impact process complexity but might still hurt you a bit on maintainability. You could go ahead and create 13 pages that each output 1 field but do not publish them. Then make a 14th page that calls each of the other 13 pages (calling them as subpages) one after the other and then have this page output all 13 items as a collection or as individual data items. What this would do is give you some insight into what kinds of problems you might encounter if you really implemented that idea but without the headache of dealing with it at the process level.

------------------------------
Dave Morris
3Ci @ Southern Company
Atlanta, GA
------------------------------

[CharlesHarder]

Thanks John and Dave,

I have been building and grouping logically based on the application itself or "common sense" such as grouping address information together in a single page output.  Our group has been discussing the pros/cons of switching to a more granular approach for 1 field per page and you have both provided some good insight and feedback.

------------------------------
Charles Harder
Automation Analyst
ATB Financial
America/Edmonton
------------------------------