Question
EY
US
Last activity: 22 Sep 2020 23:15 EDT
CLSA8: How to extend a data class to higher layers
Very tough to follow and grasp this one.
The actual problem the solution is trying to solve (assigning vehicle type as a class at runtime) is not actually stated until the end of the lesson and not directly. So, it's tough to know where things are going until the end.
The "siblings" screen shots (attached) for the Data Transforms are in 2 pieces, so very hard to line up and read.
The example given is complex and the text very hard to follow. I'm left with the impression that it was written to expand on DCR to someone who already knows how it works and not explain it to someone new to the concept. I'm on my third read and struggling - not usually the case for Pega courses.
Question: In "A possible approach to the Call super data transform option post-construction initialization problem is to use an @baseclass WasPageInitialized ValueGroup property. Every pyDefault Data Transform within an inheritance hierarchy can be altered as follows."......what is the "Call super data transform option post-construction initialization problem"? If this is not automatically set for the pyDefault DT for a Data class when created, then just check the box and set it if needed.
Thanks for your help.
Pegasystems Inc.
US
DCR (Dynamic Class Referencing) involves using polyphism to dynamically decide what rule holds the values for special set String properties. The properties could pertain to anything such as flow names or WB names, even class names. The class name can be used to set a case or data object's pxObjClass value.
What the text is says is:
- Data transforms have the ability to call the data transform in the class that the current class extends. That class would be called the “superclass”. The current class is a “sublass” of that “superclass”. (same thing as superscript and subscript).
- At the time a class was constructed it may have been at a superclass class level, not the subclass level.
- If the superclass is changed to the subclass post-construction using DCR, the pyDefault transform in the subclass should be invoked once and only once
- A Boolean ValueGroup can be used to keep track whether or not a dynamically set pxObjClass was intitialized
The Sibling figures should be 2-column TABLE elements. I will pass this along.
Updated: 18 Jul 2020 22:22 EDT
EY
US
Thanks @pedel...and maybe your explanation is what should appear in the course. I keep finding modules that are simply inaccessible on first, second and third reading - and I'm a native English speaker. I can't imagine how difficult it is for someone who is not.
It's almost as if the person who wrote it was trying to make it impossible to understand. I'm sure that's not the case, but it is the result.
Other examples of this would be the "Authorization Models" and "Establishing a Dependent Roles Hierarchy" modules.
"Access Role layering: More generic Access Roles can be created to form the authorization foundation for application-specific access roles that utilise similar personae (user roles). Application-specific access roles can then establish a dependency on more generic access roles (which may in turn depend on Pega Platform access roles), incrementally adding configuration of only that behaviour which differs between the Application layer and layers on which it depends."
and another.....
Thanks @pedel...and maybe your explanation is what should appear in the course. I keep finding modules that are simply inaccessible on first, second and third reading - and I'm a native English speaker. I can't imagine how difficult it is for someone who is not.
It's almost as if the person who wrote it was trying to make it impossible to understand. I'm sure that's not the case, but it is the result.
Other examples of this would be the "Authorization Models" and "Establishing a Dependent Roles Hierarchy" modules.
"Access Role layering: More generic Access Roles can be created to form the authorization foundation for application-specific access roles that utilise similar personae (user roles). Application-specific access roles can then establish a dependency on more generic access roles (which may in turn depend on Pega Platform access roles), incrementally adding configuration of only that behaviour which differs between the Application layer and layers on which it depends."
and another.....
"Multiple dependencies: Access roles can be configured to have multiple dependent access roles, providing multiple dependencies to defer too so that an authorization outcome can be attained, based on a collection of otherwise disparate access roles. Often there are exceptional users who concurrently perform the responsibilities of multiple personae (user roles). Creating an Access Role for these users and having it depend on multiple ‘sibling’ Access Roles from the same application may achieve this outcome."
These concepts - as presented - are neither clear nor simply put....which is exactly what a student needs in order to grasp the concept for the first time - or even as a review.
Dennis
Infosys Ltd.
US
Well said Dennis, I also got hung-up in the same place. No doubt the module is written in such a way so that no one can understand. :)
Considering this is training module It would be better if the topics are explained in such a way so that everyone can understand.
~~Shailendra