This presentation is part of the Reusability and Specialization e-Learning Course.

Transcript

Just as with Page Names, hard coding Class Names, especially in reusable layers of the class structure, can cause rules to be less reusable and force developers to do a "Save As" just to change a class name.

Task:Create an activity called AddResume in the generic class HRApp-Work.

You believe you are creating a generic activity because it resides in the generic class.  However, you hard-code the class name HRApp-Data-Resume into the activity.  The problem is that you have actually limited reuse by not using parameters.  For example, suppose MyCo was to extend the class Resume and create a new class MyCo-HR-Data-HRApp-Resume.  MyCo would then need to do a "Save As" on the AddResume activity into the MyCo work class just to change the page to the type of page created.  If MyCo did not do the "Save As" the page created would still be of type HRApp-Data-Resume, and the MyCo rules would be ignored.  By placing an explicit class name in the generic application layer, the rules at that layer become less reusable.

Our goal is to instantiate a page of MyCo-HR-Data-HRApp-Resume without having to create a new copy of the AddResume activity.  Accomplishing this goal can be done in different ways depending on how the Resume page is added. 

Follow these simple steps to parameterize the class name of the page being created:

1. Create a property, for example ResumePageClass.
2. At your work class change the AddResume activity.
3. Place the Resume page class property in the new class parameter on the Page-New method.

You can set the Resume page class property in a model or use a decision rule to set it dynamically.  An activity could consider the class of ResumePage to be the HRApp-Data-Resume instance even though at runtime it will create the MyCo version of this class.  This value is currently determined by the Pages & Classes tab.