Open Forum

Expand all | Collapse all

Organizing Extensions

  • 1.  Organizing Extensions

    TOP CONTRIBUTOR
    Posted Feb 14, 2020 08: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
    ------------------------------


  • 2.  RE: Organizing Extensions

    SILVER CONTRIBUTOR
    Posted Feb 17, 2020 11:59 AM
    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
    www.sabrelimited.com
    ------------------------------



  • 3.  RE: Organizing Extensions

    TOP CONTRIBUTOR
    Posted Feb 18, 2020 02:13 PM
    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
    ------------------------------



  • 4.  RE: Organizing Extensions

    GOLD CONTRIBUTOR
    Posted Feb 21, 2020 06:01 PM
    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
    ------------------------------



  • 5.  RE: Organizing Extensions

    TOP CONTRIBUTOR
    Posted Feb 24, 2020 08:03 AM
    Thanks Jon

    ------------------------------
    Mark Anderson
    Director of ERP Systems
    Clesen Wholesale
    Evanston, IL
    ------------------------------



If you've found this thread useful, dive deeper into User Group community content by role