In a line with the methods introduced by Partner Ready Software I am now upgrading old code to NAV 2013 R2 with the goal to modify the standard objects a little as possible.
I don’t recall Mark, Waldo, Gary or Vjeko speaking about a Table Hook but I decided to go that way anyway. As an example I have about twenty new field for the Customer Table. Instead of creating these fields in table 18 I create a new table that I call Customer Hook. The Hook Table must include the fields from the primary key and the primary key it self from the Master Table.
The only modification I do in table 18 is a new function
In a code where I need to access the new custom fields I use this function to get the Table Hook to work with.
In the Hook table I have a few functions.
Next I created a Codeunit to hook to the global triggers in Codeunit 1. This Codeunit forwards the triggers from Codeunit 1 to the Hook Table.
I need to add four lines to Codeunit 1.
When all this is ready I am able to create or extend the Customer Page. Here it is easy to mix together fields from the Customer Table and the Customer Hook Table.
For the fields from the Hook Table I can add a Table Relation and a Validate code.
On the Page I create a local function
and finally make sure that I get the Hook table matching the Customer on the Page.
I really don’t get 🙁
I understand the benefit of not creating custom fields in standard NAV tables, but I think the suggested solution has several major drawbacks:
First of all are users unable to set filters on the custom fields, and even by code it will be rather troublesome.
Secondly it requires a lot more code in pages and reports showing the fields, and you will even need to specify captions again in all the pages and reports as well.
Hi Peter
The goal here is to have the addon as an “APP” that can be easilly upgraded. I am still adding fields to tables that require a system wide use.
I then use Query object when I need a fast loop through the data.
In some pages I turn the things around and use the Hook table as the Page sourcetable.
Thank you for your reply.
Ok, I guess I have just never seen a business case matching your requirements 🙂
This is something else than the hooks pattern which can help to abstract partner/isv code from base objects. But NAV is meant to be modified.
Adding custom fields, tagged in the desciption field, is easily identified and merged, along with the code.
But this could be useful I bet…I just hav’nt got the exact case for it.
I think this is an excellent solution. Admittingly it’s a bit harder to work with in regards to filter but using the query object should be a perfect match. In a multitenenant enviroment it should be quite nice with some authentication/licence mechanism. Basically you can add layers of additional features in separate tables. This has almost an inheritance feel to it.
While I can, to some degree, agree with Peter and Johannes that this seem to take the PRS to a whole new level, I can deffenetly see the practicality of this.
Ayone in the US that have both e-ship and ChargeLogic knows, that that pretty much fills up the Sales Header table. and adding more than a few custom fields is impossible, you have to find a way to create a shadow table. And when you have to do that, I think this is the best way I have seen to do it.
Also – Taking into account the Query Object one could argue that – especially List Pages – should really be created on top of a query, and that would then open up a plethora of new and exciting opportunities for managing add-ons.