The data dictionary configuration for a transactional document looks similar, but has some significant differences from, the data dictionary configuration for maintenance documents. Here, we'll take a look at most all of the data dictionary attributes we can set to configure our document.
The data dictionary is a repository of meta-data about business objects and documents. It's the meta-data which specifically ties everything together - what form attributes should look like, what rules and document authorizers to use, what workflow routing the document should go through.
- The basic attributes
- Helpful UI Attributes
- Special Transactional Document attributes
The basic attributes
The core attributes for the transactional document data dictionary file. All of the data dictionary entries are declared in an XML file, with this general template:
This is naturally required: we need to specify which document we are dealing with in the data dictionary file, so we declare the class. Here's how it looks for Advance Deposit:
The next attributes deal with rules, authorizations, and document types - all of which are covered fully in the Document Data Dictionary page.
Helpful UI Attributes
While for transactional documents, we do need to create JSP pages for the view, the Kuali Nervous System still allows us to specify some of the look and feel for the JSP page within the document data dictionary. Some of those fields, such as label and help, are covered fully in the Document Data Dictionary page. However, some - such as attributes and header navigation - are very specific to transactional documents.
Most transactional documents tend not to have associated business object data dictionary files. However, sometimes transactional documents need certain pieces that business object data dictionary files have, specifically attribute lists. Those can be declared in the transactional data dictionary file itself. For instance, /org/kuali/module/financial/datadictionary/docs/CashReceiptDocument.xml declares attributes for the document's check, currency, and coin totals, as well as total for the entire document. Since these are attributes of the document itself and not any related child business objects, the data dictionary has to define them. These are defined just as they would have been in a business object's data dictionary configuration:
The documentNumber should NOT be included among these attributes; it is written to the page via the kul:documentHiddenVariables tag, as we'll later see, and any attempt to write it out with attributes as well has been known to cause...issues.
Inclusion of attributes in a transactional document document configuration is fairly common, even though these configurations are for documents and not business objects.
Transactional documents can also declare their own, internal tab system. Indeed, the two transactional documents in KFS Research Administration use headerNavigation to create a system of intra-document navigation. In the screen shot below, for instance, we can see the header tab menu as it is used in the KFS RA Routing Form; currently, the "Research Risks" tab is the tab with focus.
Each tab of the navigation header, in turn, has its own Form and Action classes and its own JSP page, and each tab is mapped separately in struts-config.xml. Obviously, this work is quite involved but is useful for highly complex documents.
Special Transactional Document attributes
There are two special tags, one of which is required and one of which is often used, to mention for transactional documents.
Some transactional documents can be copied directly as new transactional documents. This ability can be turned on or off using this tag. The Advance Deposit document turns it on, for instance:
allowsCopy isn't required; it defaults to "false." Of course, it won't work at all unless the class for our transactional document implements the org.kuali.core.document.Copyable interface.
This tag is required for Transactional Documents. It specifies whether the document can be referred to by an error correcting document, such as the General Error Correction or the Year End General Error Correction. Here, the Advance Deposit document disallows error correction: