DO'S AND DON'TS IN MAXIMO

• Don't fetch MBOs in the init() method. If MBO needs to be fetched, do it in initFieldFlagsOnMbo().

• The constructor should only be used to call super and set some instance variables.

• Should never execute methods that could call exceptions.

• Don't ever use a mbo or mboset class as a event Listener, it will never get garbage collected.

•  Don't ever put a mbo/mboset as static anywhere.

• SAVE - Don't call save in business logic code.

• If two MboSets contain Mbos pointing to the same record in the database and you modify    both you will get "Record has been updated by another user". That is why you should use the same relationship to obtain the record.

•  Avoid repeating logic, reuse MboSets and MBOs

• The modification of a MboSet that hasn't been saved can be obtained from the same relationship from the same parent, if you use a different relationship you won't see the change.

• Validation method should only do validation and the action method should only do business logic. Do not perform validation in the action method.

• The validation method can be customized to verify whether the new value for the attribute is valid.

• An action() method may then be executed. Action methods contain business logic and updates to other objects.

• Never modify existing class just extend the class and write your logic in the program

• Use domains as much as possible rather than using Fld classes

• Domain and FldClass could co-exist.

• Consolidate Domain and FldClass if possible .Validation occurs for both.

• Everything in the Field Class will be executed except for the getList(). The list will come from the domain that is defined.  If a domain is not defined the list will be fetched from the field class.

• MaxLookupmap - key mapping for lookup and goto app.

• Better to be implemented in table and not in fldclass.

• Population of value should be defined in that fields initvalue, not in MBO's init.

• Two classes can be associated to an attribute. MboValue and Validation Class.