Rethinking the Classgroup
Classgroups have historically provide three benefits. First, they allow multiple classes to share the same table. Second, the group the classes in the class explorer.
Third, they provide a common base for finding the application's processes.
This first purposes is specious. Even without the classgroup, classes will share the table of the pattern ancestor. And following classical database design, you might as well assign classes to particular tables.
The second purpose is helpful: grouping is good. But why group only at the work level? As we regularly group at the work level, we end up missing all of the auxillary classes and then needing to hunt through the explorer for them.
So why not set the "ClassGroup" to be MyCo-FW-App? This would cover MyCo-FW-App-Work-, but MyCo-FW-App-Int-, MyCo-FW-App-Data-, MyCo-FW-App-Rule-, etc.
So let's look at this third purpose. If we want to automatically list all of the processes -- of marginal benefit -- we can still do so if the ClassGroup is a higher level.
I am trying this with my new App. Part of the complication is that the application accelerator has already created MyCo-FW-App-, which Pega asserts is the common ancestor for all of the classes underneath. Since it's abstract, it can't be a classgroup. And since it is thought to be the common ancestor, it can't be deleted.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Keep up to date on this post and subscribe to comments