Documaker Development Standards and Guidelines

Question

Hello experts -
I'm wondering if any of you (or Oracle for that matter) would be willing to share a document of your Documaker coding standards. I'm looking for things such as:
1) Naming standards for sections, forms, etc.
2) Guidelines for data mapping (i.e. always map to the XDD; never map directly to the XML)
3) Guidelines for how to break a form up into sections.
I'm looking for things of this nature. We offshore a lot of our development and want to make sure that a consistent standard is used.
I will probably end up creating my documentation from scratch, but thought I'd check.
Thanks in advance,
Dave

Answer 1

Hi,
I am just giving few pointers from my experience. However, this list would not cover things in an exhaustive manner.
1) Naming standards for sections, forms, etc.
Generally, it is advisable to keep the form name in sync with the Business name of the form. So that, we would not require a document to translate the Business form name to the Documaker forms whenever a future requirement or enhancement is requested. However, if the Business form name is too long have the descriptive text, you can put that description under the Form Description property and have a unique sub string as the Form name.
For sections, it is always better to have appropriate prefix and suffix so that the maintainability becomes easy for the company. I would suggest few things as Naming standards that will help the future maintenance.a) Have all sections with Signatures, Logo, Address - better prefix the Section names with SIG, LOGO, ADDRESS respectively.
b) Please prefix with texts like FOOTER, HEADER, BODY as part of the Section name to make it more clear. This will also help developers to implicitly understand what kind of sections they are working with.
c) When you have multiple State variations, please suffix appropriately in the Form or Section names. Say Form A 00 represents Countrywide version and Form A FL represents FL State variation etc.
2) Guidelines for data mapping (i.e. always map to the XDD; never map directly to the XML)
It is always advisable to go with XDD mapping under the following circumstances:
a) Whenever data is going to be mapped from Common records.
b) Whenever a field is going to be used in more number of sections.
Having field definitions in XDD, will help us in easier future maintenance. But one thing we will have to keep in mind is, a field in XDD will be helpful as long as it is expected to show the data from same field in the extract, with the same masking rules in more number of sections/ forms. We can however override them in field properties from individual sections, but this will defeat the purpose of XDD usage and its advantages.
3) Guidelines for how to break a form up into sections.
This is purely dependent on the nature of the form you are working with. But here are few pointers.Create or break a form in to multiple sections for contents falling under the categories listed below:
a) Special contents like Address, Logo, Signature, Barcode etc. It is always easy to maintain, re-use, control and assess any future changes.
b) Any other Headers, footers content. This will give you the advantage to make use of the Print controls like Copyonoverflow, FirstOnly, LastOnly etc. Also, you can do a better management of these content when created as separate sections like re-usability, templates, standard X,Y positioning using Section rules etc.
c) Dynamic tables, so that you can control the dynamic overflow or repeating logic. It is also advisable to create the Table headers, footers as separate sections so that you can take advantage of SetGroupOption rules.
d) Any content which is used in more than one form - when you break it and design it is a separate shared/ common content, future changes can be made simple and controlled.
Thank you.
Edited by: Nirmal Garga on Feb 7, 2012 4:43 PM