Experience with Hooks Pattern?

zeon

Hi,

I would like to know if anyone here on the forum has experience with the Hooks Pattern discussed on the design pattern page and also on Waldo's blog?

I am interested in knowing how to deal with small assignments in the code, e.g like:

SalesLine.Quantity := MyNewLine.Quantity

According to the pattern everything is pushed to the hook function, so what about small one-line assignments. Do you also push them?

And how to handle situations where you need the return value to decide whether to exe one part of the code or another?

I would like to see some more examples than shown in the article and hear about general experience with the pattern.

/zeon

tinoruijs

zeon wrote:

SalesLine.Quantity := MyNewLine.Quantity

According to the pattern everything is pushed to the hook function, so what about small one-line assignments. Do you also push them?

Yes, also small assignments, because sometimes/often it will not be the last line you need.

zeon

I agree with you, that you should also push small assignments to the hook function as you probably need to add more along the way.

Have you worked with the pattern, and what is your experience...any shortcomings?

And what about naming conventions when I add code to e.g "Quantity - OnValidate". What's the preferred naming for that hook function? OnQuantityOnValidate or OnValidateQuantity...or...

tinoruijs

I must say I have not yet read the pattern on this page: https://community.dynamics.com/nav/w/designpatterns/117.hooks-pattern.aspx
Gonna do that. :-)
I've learned about the pattern from Waldo at NAVTechdays.
So I started using it in my latest projects. But I do not yet use naming conventions. Gonna do that in my next project I think.

einsTeIn.NET

zeon wrote:

I agree with you, that you should also push small assignments to the hook function as you probably need to add more along the way.

I think it depends on if you think it's necessary to do that. I mean if there are several assignments on one record anyway then why don't put in another, especially if the Object isn't touched apart from that.

zeon wrote:

Have you worked with the pattern, and what is your experience...any shortcomings?

I think in general it's a good idea to ensure that you don't corrupt a standard object when you update and/or merge. On the other hand, you need a lot of additional codeunits (depending on how many parts of NAV you use).

zeon wrote:

And what about naming conventions when I add code to e.g "Quantity - OnValidate". What's the preferred naming for that hook function? OnQuantityOnValidate or OnValidateQuantity...or...

We name it e.g. T37OnQuantityValidate. So, basically it's [Object]On[Fieldname][Action].

Miklos_Hollender

Why does the pattern prescribe a different Codeunit for every function? This looks suspiciously like what an add-on developer would do: for them it can be useful because this way it is possible to have different granules / modules inside the add-on and install only a part of it, and they don't need to be frugal about the number of objects used.

But a "normal" customization developer would not do this, no advantage, and hard to explain to the customer why they need to spend money on buying Codeunits.

Here us how I done it since about 2002: I pretty much automatcally sell table, form/page, report designer with every project and the objects that come with it. If the customer is called Cronus Ltd. the first thing to do is to make a Cronus Setup table. And form/page. Any change requested gets a setting here like a checkmark to turn off and on, for safety and it also serves as a quick documentation, just looking at this setup reminds you what was done for this customer.

And pretty much every code is a function in this table. What is even the point of codeunits, other than to regulate licence ranges or user rights? A function is a function everywhere. So, yes, it is then filled with functions like TableSalesLineQuantityValidateBefore and TableSalesLineQuantityValidateAfter. This makes merging a whole lot easier.

I think it would be useful if add-on patterns and customization patterns would be more separated. This is a good customization pattern.

tinoruijs

Miklos Hollender wrote:

But a "normal" customization developer would not do this, no advantage, and hard to explain to the customer why they need to spend money on buying Codeunits.

Here us how I done it since about 2002: I pretty much automatcally sell table, form/page, report designer with every project and the objects that come with it. If the customer is called Cronus Ltd. the first thing to do is to make a Cronus Setup table. And form/page. Any change requested gets a setting here like a checkmark to turn off and on, for safety and it also serves as a quick documentation, just looking at this setup reminds you what was done for this customer.

Nice solution such a setup table!

Navitrans_fvet

How should hooks be ideally integrated in multi-branch developments? Suppose the OnValidateQuantity hook from the original post is added in our W1 add-on.

The localized BE add-on on it's turn also wants to further customize the OnValidateQuantity hook. Would you have to add the extra hook in the hook codeunit? Or create a second hook in the original code?

On top of that, the BE add-on is used for a customer implementation, needing extra customisations on the hook.

At the end, how would the 3 hooks (W1, BE, Customer) have to be implemented and how would that increase the readibility of the application code?

Miklos_Hollender

Yes, but I don't use a codeunit for every hook, I don't want to pay so much for custom objects. Protip: people who write these design patterns generally think add-ons, not customizations, so they have many "free" objects.

A good customization pattern. You have a customer called e.g. Cronus. They buy table, form, report designer. Get 10 tables. You create table 50000 as e.g. Cronus Customizations Setup. Same way as e.g. Inventory Setup. For every customization you do, you put there a configuration and at least one boolean field that tells you to turn the customization on or off in a certain company. This is also very useful because this page and table works basically as a simple documentation. When you hand over your client to your support department, you can show them this table and page and tell the support basically these are the custom stuff here, rest is standard.

And then you can put all your hook functions on that table.

I also think in 2016 these are events now, not hooks? Did not look into it yet.

mdPartnerNL

there must be some codeunits or tables you can use from the upgrade range? these are in the license and after upgrade you can use them again..