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:
  • Keep the group models as small, flexible and independent as possible by using a separate group model for each pattern.
  • Avoid using Foundation class objects. Rather go back to the origin of the pattern library objects to be more independent and flexible.
  • Hold all necessary class objects together by scoping them by a container entity. Exceptions are objects which cannot be scoped (variables, names). Give this container object a meaningful and unique name, describing and identifying the pattern as a whole.
  • Group model names may be treated flexibly. For this reason any name may be used. We might rename the group model name (directory) after acceptance to avoid name conflicts and match the PatternFactory naming standards for patterns. All the more it is important that you use a clearly understandable container name.
  • If your pattern library consists of several sub classes, build a container entity for each of them and scope them all by one superordinate container entity.
  • In addition, arrange your class objects by dividing your primary container entity into further group and sub group objects like entities or functions (fields only can be scoped by functions!):
    • an entity called Aux for any kind of auxiliary objects, if existing (e.g. functions, fields, messages, scripts, source codes)
    • an entity called ReplObjects for abstractly defined objects used by the class itself (e.g. views, functions, fields) to be replaced in the end when going life
    • the actual class object called Class, mostly being a function or an entity
  

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.

Packaging

  • Pack the contents of your group model directory into a zip file. The subdirectories \Backup and \Locks are not necessary to be delivered and for this reason may be omitted.
  • Enclose a ReadMe text file in the zip file with the following contents: