As we have seen in our previous few posts that in DYNAMICS AX, we have number of methods that can be overridden on FORM as well as at DATASOURCE level. The primary purpose of overriding the methods at FORM level, DATASOURCE level or Field level is to perform User actions.
User actions on a form are input through mouse pointers and keyboards. I would recommend you to go through this MSDN post to understand and learn about recognized events and their sequence.
It is always a best practice to write the code at class level so that it can be re-used. In dynamics ax, you can see number of Classes. already defined for different purposes. The methods of Classes can be used in Tables or Forms and also we can apply object-oriented principles such as Inheritance, Polymorphism, Encapsulation etc.
For example, while doing student course enrollment or student registration, we have number of common methods related to Student Entity. We must encapsulate these methods in Student Class and reuse them in Student Table and Student Form. Let's say a registration number is generated every time there is entry in Student Table, the logic of generating the registration number must be placed in a class so that if a user has been given the facility of registering the Student at different forms, it should invoke every time the same method defined in a Student class.
Therefore, we should always try to write lines of code firstly at Class level and secondly at Table level as much as we can.
You can also see the same methods while overriding the methods for DATASOURCE level that are already available at Table level. I am going to share with you a snapshot as shown bellow where you can see few same methods at Student DATASOURCE available for overriding that are also available for overriding at Student Table level such as validateWrite() and validateDelete().
User actions on a form are input through mouse pointers and keyboards. I would recommend you to go through this MSDN post to understand and learn about recognized events and their sequence.
It is always a best practice to write the code at class level so that it can be re-used. In dynamics ax, you can see number of Classes. already defined for different purposes. The methods of Classes can be used in Tables or Forms and also we can apply object-oriented principles such as Inheritance, Polymorphism, Encapsulation etc.
For example, while doing student course enrollment or student registration, we have number of common methods related to Student Entity. We must encapsulate these methods in Student Class and reuse them in Student Table and Student Form. Let's say a registration number is generated every time there is entry in Student Table, the logic of generating the registration number must be placed in a class so that if a user has been given the facility of registering the Student at different forms, it should invoke every time the same method defined in a Student class.
Therefore, we should always try to write lines of code firstly at Class level and secondly at Table level as much as we can.
You can also see the same methods while overriding the methods for DATASOURCE level that are already available at Table level. I am going to share with you a snapshot as shown bellow where you can see few same methods at Student DATASOURCE available for overriding that are also available for overriding at Student Table level such as validateWrite() and validateDelete().
Since you must have an idea after going through MSDN posts that validateWrite and validateDelete performs validations before writing or deleting records respectively. The best place to define the methods that are available both at table level and form level is table level. However, based on any particular scenario, these methods can also be overridden at form level.
For example, after defining the validateWrite() at table level, we can also define the same validateWrite() at DATASOURCE level. validateWrite() at DATASOURCE level will be invoked at first, then it will invoke the validateWrite() at table level by invoking super(). We can find whether validation at table level returns true or false by invoking super() at DATASOURCE level.
There are a lot of problems and issues we can find in dynamics where we would require only little piece of code or some where we require no any code. Therefore, we should be aware of all the important methods and their proper usage and sequence. Also, some times you fix any issue to do an implementation only setting a property instead of writing code, so I will recommend you to go through all important properties and methods in the MSDN. I always try to keep my posts as precise and I can, I hope you enjoy reading my posts, I will be waiting for your feedback comments.
No comments:
Post a Comment