There were a lot of new concepts in this recipe. The first was the use of the table handler class, forgetting the attribute-based constructor for now.

The table handler is useful when the logic gets very complicated and would benefit from being abstracted into a class structure.

If you compare the Insert, Update, and Delete methods to the way this was done in SalesTable and SalesTableType, you will see a key difference. In SalesTable, the call to super() was removed and the handler class calls the equivalent do method directly. Since the standard Insert, Update, and Delete methods simply call the equivalent do method anyway, this may seem fine.

There is a drawback, which detracts from the aim of making our code extensible. This is that the table events, those that live under the Events node in the table designer, do not fire unless super() is called, effectively disabling the events for insert, delete, and update. This is why the table event OnInserted on SalesTable will not fire.

The SysExtension framework is genius, but should be used with care. By using this, we have increased the overhead of writing records to the table. The practical difference may be small in this case, but should we have used this on transactional tables like InventTrans, the result could be significant.

The class is instantiated by looking at the classes that extend the base class (as specified in the call to SysExtension::getClassFromSysAttribute) for classes that have the appropriate attribute decoration.

This means that another party could extend the enum and write their own class to handle it; no over-layering is required, and we can ship updates regularly without causing our customer undue pain as they apply them.

The form was hooked up using a pattern that can be seen throughout Operations, although, the handler is sometimes constructed from the table and not the data source. This means that calls to the handler class must include the current record, which is not required in the pattern used in this recipe.