You remember NAVTechDays, right? The place where a lot begins, and a lot happens. 🙂
Well, I explained in my wrap-up of NAVTechDays2013 that there was (some) attention on something called “The Hooks Pattern”. Because of that – I dedicated a topic, specifically on the Hooks-pattern (which was also handled during our Pre-Conference Day workshop on “Development Best Practices for creating Partner Ready Software“). This seemed to have been a good thing, because we got quite some feedback on it, like “dude, you just solved my million dollar question” :-).
Where can I find this pattern?
Since a while now, I have published the Hooks Pattern on the Wiki. (“The Wiki”? Sure, the Wiki about NAV Design Patterns. You know .. you can find it here. Check it out, read it, and enjoy!)
What can this “Hooks Pattern” do for you?
Well .. in my opinion, quite a lot. We implemented this pattern internally in our product in kind of an “insane” way. Or let’s say “quite obsessively” .. or let’s say “very consequently” (that sounds more positive ;-)).
And with result: we were able to do a localization from W1 to BE in less then 30 minutes merging (which took us up to a minimum of 2 days with our old product – which only differs in design). After this localization, we did an upgrade to NAV2013R2 (which changed about +1400 objects, of which we changed 337 objects. So 337 objects to merge, which we did in 15 minutes. I must admit, we did all this with the Mergetool, which does a great job in combination with this pattern.. .
So .. I’m sticking to the pattern in the same insanely, obsessive consequence.. :-).
Any remarks are always welcome!
Loading ...
6 comments
5 pings
Skip to comment form
Hello waldo,
I’m a big fan of the Hooks pattern and every developer in our company is happy about this. It is good to have a common denominator in the NAV community.
After some weeks with this one question always pops up:
What should we do if we have to disable/uncomment standard code? For example if you have something in sales-post which you don’t want to happen. The Hooks in your pattern are mostly OnBefore,OnAfter events, but what if I just have to plain disable some parts in standard code?
Did you already think of a systematic for that? Currently the only solution I could come up with is uncommenting that codeblock and create an “InsteadOf”-Hook for that code. So like “InsteadOfInsertTrackingLines” after the codeblock I disabled. Is that the Best Practice or do you have another system for that? Could we in the community come up with some standard-naming for the “InsteadOf” hooks? I was very happy to see another NSC using the hooks pattern, with the same “OnAfterInsertDocument” naming convention of the hooks.
Anyways, thank you as always for your awesome work. I’m so happy how the whole pattern thing works out currently. I really hope we will see more progress in the standard code in the next years, using the stuff you and the other guys defined as a common good practice.
Greetings
-Thomas
Author
Good to see you’re a big fan. I’m a “maniac” myself ;-).
To me, hooks is all about limiting the amount of code you have to change. so to comment code, I try to do something like:
IF hook.OnBeforeTheCodeThatIsAboutToBeExecuted THEN …
and the hook-function should return a FALSE when code should be commented.. . I like the “Insteadof”-naming though – but then again, you already assume the code is going to be commented – while this might change in the future (by changing the boolean).. . If that makes sense at all ;-).
I have about 20 hooks in codeunit 80, all describing the exact place what the code is doing there, like OnBeforeCreatingSalesShipment .. and things like that.
Hello Waldo,
Thanks so much for your great work out here.
I’m unable to access the link for the “The hooks pattern on the wiki” , nav design patterns.
Author
You can find it here:
https://alguidelines.dev/docs/navpatterns/patterns/hooks/
Hello Waldo..
I’m unable to access the links to the Design patterns
Author
We moved it here:
https://alguidelines.dev/docs/navpatterns/
[…] Continue reading » […]
[…] yeah .. almost forgot .. we implemented the hooks pattern quite extensively at my company. Well .. I can tell you this: using these commandlets, I’m […]
[…] mean .. think of it .. there are design patterns that facilitate upgrade .. which many of us embraced as being good practice! These patterns basically minimize the […]
[…] “Hooks” helped me a lot again this time as well. Putting them into the refactored code was quite easy. I spent more time on some pages then I did on Codeunit 80. […]
[…] “Hooks” helped me a lot again this time as well. Putting them into the refactored code was quite easy. I spent more time on some pages then I did on Codeunit 80. […]