Subscriber Codeunits #92
Replies: 4 comments 23 replies
-
@waldo1001 takes it |
Beta Was this translation helpful? Give feedback.
-
The pattern should include a naming convention for subscriber procedures. For Integration and Table/Page Trigger events I propose: If one adheres to this naming pattern (combined with bundling events) it will enable the compiler to detect duplicate event subscribers. This will help minimize the number of event subscribers in an extension. |
Beta Was this translation helpful? Give feedback.
-
You really approach features as mini-apps, apps within apps, applets, app-ushkas haha. I see the sense in that looking at it from a pov of organizing the objects but I'm just not sold on it. I've seen a bunch of apps that do that and it can get really messy that way. Then you see the dozens and dozens of apps that companies throw into extension management, and you think about all the features/applets inside of those. Just makes me shiver with all the 'stuff' that is in there. |
Beta Was this translation helpful? Give feedback.
-
Question: We have the chance to use a Subscriber to a field like
or in a tableextension
How does this have effect to performance. As understood the EventSubscribers do have a effect, because they have to be loaded in memory on execution. But when i have it directly in the extension, i imagine that the code is already loaded by reading the object and so it could be faster this way. How do you see that? |
Beta Was this translation helpful? Give feedback.
-
Subscribers are the new standard - but what are the best practices in subscriber-codeunit design?
Thinking about:
more?
Beta Was this translation helpful? Give feedback.
All reactions