Organizing Extensions
-
Organizing Extensions
Posted by Unknown Member on February 14, 2020 at 8:02 am-
Hi All
We’re just about to embark on some extension development (we’re on-prem), some mods will be simple stuff like
- Caption Changes
- Making fields visible
Others are basic changes
- Cues
- Table and Page Extensions to add a few fields
Wondering what best practice is. Clearly, I don’t want an extension for every single minor mod. I would imagine any major mod would be it’s own extension.
What’s best practice for combining unrelated stuff (e.g. a caption change on page Y; a table and page extension for table/page Y; report Z)
With VSCode, would you make a folder for each “mod”?
Thanks
Mark
——————————
Mark Anderson
Director of ERP Systems
Clesen Wholesale
Evanston, IL
—————————— -
Hi Mark,
We’ve been writing extensions now for about 2 years for on-prem customers in 2018 or BC as well as for the cloud.
Here’s some things to keep in mind:
1) We are finding that it’s easier to just use one “big” extension so long as the customizations are not intended to be aĀ separate “applet”.
2) When you have multiple extensions, you need to make them dependencies to be able to access any changes made in Ex.1 while programming in Ex.2. This can become tedious. It also slows down deployment a lot.
3) We have not tried to isolate the different “requests” of users in any way.Ā We have an issue tracking system, so we may insert a comment in code citing the issue number that lead to creating that bit of code – but well named variables and fields and the nature of AL means it is fairly self documenting.
4) We have not split code so that we have more than one page extension or table extension for the same table or page.
5) The only exception we might make to the above may be to put all Tables and Table Extensions in one extension, and everything else in another (courtesy of PrintVIS). This is because the older versions of NAV/BC Web Client (NAV 2018 for instance) personalization “extensions” that are created by users can cause a little extra work and having the tables in a separate extension makes it a bit easier to manage.
6) We follow the best practice (there is a VS Code extension in their app market) and split our AL files into folders for pages, page extensions, tables, code units etc…Hope that helps,
-Rob
——————————
Robert Jolliffe B.A.Sc, MCSE, MCS – NAV Manufacturing Expert
President
Sabre Limited
Cambridge
robert@sabrelimited.com
http://www.sabrelimited.com
——————————
——————————————- -
Thanks a lot Rob.Ā
Very useful info.
I had read about the pain of managing dependencies
Mark
——————————
Mark Anderson
Director of ERP Systems
Clesen Wholesale
Evanston, IL
——————————
——————————————- -
While a best practice has yet to be defined for this, i.e., one giant hairball extension, many small extensions or well thought out granuled extensions, it is clear that it is easier to just do one giant hairball. But, think about the future. One thing extensions give you is self documented customizations. Just open the extension page and you see all your extension that are installed. There clearly can be future value if you have multiple extensions. They should each provide specific functionality, and like others have said, avoid cross dependencies. Dependencies in themselves are not bad, but, more than one layer is bad.
Also, from my conversations with MVP’s and from experience, it will be nearly impossible to detangle a large hairball in the future, should there be a need. So, my advice is to do it the hard way and split it out into sensible smaller extensions. At least it will eventually give you value and won’t put you in a position where you have no choice but to live with a giant hairball with no simple way to detangle.
——————————
Jon Long
Director of ArcherPoint-Upgrades
ArcherPoint Inc.
GA
——————————
——————————————- -
Thanks Jon
——————————
Mark Anderson
Director of ERP Systems
Clesen Wholesale
Evanston, IL
——————————
——————————————-
Unknown Member replied 5 years, 6 months ago 1 Member · 0 Replies -
-
0 Replies
Sorry, there were no replies found.
The discussion ‘Organizing Extensions’ is closed to new replies.