The Best Practices of Adaptive Forms (including uses in JEE Workbench)

This document is a working document. I have a number of personal best practices that are habit and not documented. This document should be considered a living document where items are added as they are discovered or shared by others.

• Adaptive Forms:
  • Object Naming Conversions:
    • Panels
      • Panel names are camel case starting with an upper case character. IE: “MyPanelName”
    • Fields:
      • Field names are snake case starting with a lower case character. IE: “myFieldName”
      • Note that JavaScript naming conventions are not forced in the “Element Name” field.  As of this writing, a field named “123-HelloWorld” is acceptable. If you attempt to use JavaScript against fields that are improperly named, your JavaScript may fail.
      • Do not start field names with numbers.
      • Do not include dashes “-” in your names. These will equate to a minus sign in your code and will act as operators in your code.
      • Names can contain letters, digits, underscores, and dollar signs.
      • Names must begin with a letter
      • Names can also begin with $ and _. Don’t use these though, they are frequently used in underlying frameworks like jQuery.
      • Names are case sensitive (y and Y are different variables)
      • Reserved words (like JavaScript keywords) cannot be used as names. Watch out for other AF-specific reserved words such as “panel” for example.
  • Object Events:
    • Visibility:
      • Code related to the visibility of an object should always be placed in the visibility event of said object. IE: A “company name” field should only be visible if “Are you apply as a company or individual” is set to “C”. You do not attempt to change the visibility of the “company name” in the value commit of the type field. This ensure that you don’t have to repeat the same code from the commit to the initialize (if it’s used in a workflow) but also makes the form easier to debug and for subsequent developers to follow. If a panel or field is not visible, the developer simply needs to go the visibility of that event and not traverse the entire form for code that changes the visibility of other objects. You do not need to inherit this coding pattern from XDP to Adaptive Forms.
  • Script
    • Length:
      • If the code you are writing inside an Adaptive Form extends past 5 visible lines, you must move your code to a Client Library. Ideally, add your function to the client library and then add the appropriate jsdoc tags to allow the function to be visible in the Adaptive Form rule editor.
• Project:
  •  Folders:
    • Naming:
      • When creating JEE Applications from Workbench, an associated folder will be created in the Forms directory (/content/dam/formsanddocuments) with type “lcApplication”. Folders you create to store your Adaptive Forms should be named with a suffix of “-af”. ie: If a JEE application is named “MyApplication”, the corresponding folder will be named “MyApplication-af”. Acceptable variables on this has been “-forms”. Note that this rule only applies to JEE instances where JEE applications need to be matched with Adaptive Forms.
    • Structure:
    • Services that will be exposed to the outside wall through the firewall should be placed in a clearly indicated folder such as “public” or “external”.

OSGi Workflow Models

• Assign Task
  • Route Variables must be unique for each Assign Task step. These steps are only  stored in the JCR in one metadata location. Therefore, each use of the assign task will overwrite the route variable allowing you to see the last choice only.

Custom DSC’s

The component ID should be prefixed with “CustomDSC” to allow clear identification of custom services to the system administrator. The same is true for the category id. Developers should be able to clearly identify which services are pulled from custom services.

Developers: You should not use a custom DSC without first confirming that you have access to the source code or resource that has access to this resource. Code for DSCs tends to not be version controlled properly at times and code in these components needs to be recompiled when new JDKs are used when upgrading AEM / LiveCycle.

<component-id>CustomDSC_MongoDB_CRUD</component-id>

<auto-deploy major-version=“2” minor-version=“0” category-id=“CustomDSC_MongoDB_CRUD” />