
PatternFactory Developer Standards
Introduction
This document describes the standards to be used when developing patterns for the PatternFactory share platform.
These rules should help the PatternFactory patterns to appear and to be used in the same or at least similar way
(cooperate identity!). They have to be seen as addendum, not as replacement of your own standards. They do not claim
to be complete and are subject to change.
Fundamental Idea
The PatternFactory patterns are small and compact Plex class libraries, including class objects of high using comfort for
developers and users, with highest possible flexibility and independence of existing classes, but without limitations. It
should be possible to primarily use the classes by external settings (inheriting, replacing, scoped messages and field
values). Mandatory amendments to the action diagram should be kept to an absolute minimum. The generated code
should be optimized and compact without unnecessary instructions (no overhead).
“Build your application by gathering (is a) and setting options (replacing)!”
Keep Things Compact and Tidy (Structure)
Making use of classes often can be quite tricky, even if you know them well. Often you have to gather the necessary objects from various places, having to browse objects from the same or even different object types. Therefore, the goal is to facilitate this process:
|
![]() |
Action Diagramming Rules
- We expect your code be clearly arranged and to conform to the structured programming rules.
- Put your detail code into subroutines.
- Append the fully scoped function name in brackets at the end of your own subroutine names. Makes it very useful when merging functions by multiple inheritance to see the origin of every subroutine.
- Build subroutines in the same way as the standard Pattern libraries by CA do (+++Define +Subroutine, start edit point, with +Subroutine meta conditioned mainline with additional edit point(s) if appropriate , end edit point, +++Undefined +Subroutine)
- Append the fully scoped function name in brackets at the end of your own edit point names. This way in the local modification view and in the edit point dialog of the AD Editor you always know immediately where the edit point is located.
- Place your subroutines in Pre Point Subroutines. This way the Post Point Subroutines stays free for any user amendment and thus stays easier to navigate.

- Avoid unnecessary generated code by using meta conditioning where ever you can.
- Document all your code and have a modification log at the beginning. Append the fully scoped function name in Brackets at the end of the text, so the origin can be found out.
Documentation
- To keep things compact, tidy and easy to maintain, we chose to use the Plex model narratives facility to document the patterns. Enter your documentation into the narratives of the class container entity.
- The documentation should consist of:
- Date and Author
- Title
- Description of the pattern
- Implementation rules, detailing the steps to take to achieve the requested application object.