Источник:
http://erconsult.eu/blog/sysextensio...ework-pitfall/
==============
This research has been inspired by a real bug in the D365FO v. 10 (preview) application. It turned out that the
SysExtentionAppClassFactory doesn’t explicitly call the
new() method the 2nd time when it takes a previously resolved class name from the cache.
This is just good enough to pass an automated test or to fool a lazy tester, but in real life this may potentially result in run-time errors or other misbehaviour. Any code, any internal variable initialization you placed in the
new() constructor is going to be bypassed the second time you call the same operation within the same client session.
To illustrate this, let’s use the demo project from my other
blog.
Add the following code into the new() method of the
MealCourse class:
abstract public class MealCourse
{
...
protected void new()
{
info ("Yummy!");
}
}
Create a new action menu item to call this class, and place it on any of the D365FO menus. Call it once:
Right, yummy-yummy-yummy!
Call it again from in the same window (do not reload the browser but just click the menu item the 2nd time):
Nothing. The new() method has not been called.
Conclusion
Do not rely on the new() method when using the
SysExtension framework. Let it be empty, do not put any logic at all inside. Perform the variable initialization in a dedicated method or any of the parm() methods, and call them explicitly in your constructor right after the
SysExtensionAppClassFactory ::getClassFromSysAttribute() call.
The post
SysExtension framework pitfall: avoid new() appeared first on
ER-Consult.
Источник:
http://erconsult.eu/blog/sysextensio...ework-pitfall/