AL Extensions – File Naming and Organizing

This is a blog that I wanted to write for quite a while, but it’s only until last week or so that I think I’ve found what I like to call, a “best practice” or if you will, a “Design Pattern”.

What is this all about? With the move from C/AL to Visual Studio Code we also moved to file based instead of stored in database.

This means we also have to give these files a name and we have the option to organise the files into folders, or subdirectories if you are a born-in-dos generation.

If you follow the Microsoft guidelines and/or use the tooling from Waldo your extension your extension will probably look something like this:

Although this works perfectly there are a few issues with this that I don’t like. I’ll try to explain myself.

Object ID’s

The Object ID is still there. Not perse a big problem but in the cloud they don’t mean anything anymore except making the object Unique. In the past, we as developers tried to use object ID’s in a smart way, like make sure that table & page have the same ID, or make sure that Header and Line tables have adjacent ID’s so Object Designer in C/Side would show them nicely grouped.

In most projects as well as in Microsoft’s BaseApp this is no longer true and possible. We have too much legacy to trust sorting and grouping objects by ID.

Prefixes

If you prefixed your objects in C/Side and run the conversion your filenames look something like this.

To me this looks like a horrible waste of the first 15 or so characters of your filename. I tried it for a while and it’s very hard to work with.

Abbreviations

For reasons of legacy object names in AL can only have 30 characters. On top of this you’ll loose 3 or 4 on the TLA you need to mandatory put in my Microsoft. This often leads to horrible object names which are then converted to your file name

Lack of Intent

If all of your projects have the same object tree it does not make it very clear what kind of extension you are looking at. By opening the project we can only recognise it as an AL project but we cannot see what it does.

I can hear you say, so what? What do you suggest we do Mark?

BaseApp

When I opened the BaseApp in AL I got the first Aha moment on how to solve this puzzle. To my surprise Microsoft was not following their own guidelines.

It would not be the first time they don’t follow their own guidelines and at first it pissed my off a bit. But only untiil the beauty of this naming pattern struck me just like that.

With these naming guidelines you can automagically see what belongs together regardless of the Object ID and Object Type

Old Naming Conventions

For those of you who remember the old Solution Developer materials will also know that there are strickt naming guidelines. Like the Table Name is singular, the Page Name is Plural. If you have a List and a Card you name them like that etc, etc, etc.

If you were religious about these rules and follow this pattern your project suddenly makes much more sense to look at.

Subfolders

So I hear you say, what about subfolders? The BaseApp has over 6000 files and this naming does not make it easy to work with if everything is in one root folder.

The logical answer here is to apply common sense. Group your objects together if they belong together.

Clear Intent

This also gives your project a clear intent. I can see by looking at the folder structure that this is a report pack with Labels, Sales Taks reports, Financial reports, and so on, and so on.

Remove Abbreviations

If you remove the abbreviations and then look at for example a Journal the pure beauty of this way of working with files becomes as clear as sunshine on a cloudy day.

See how nice the Batch, template and register are grouped together and it’s very easy to find the file you need.

One can debate if in this specific case the word “Example” is overkill, but if you think for a moment it would say “Item” I’m sure to think you agree with me.

Call to action

To me this is another indication of how smart one of the old Navision rules were and it looks to me that Navision was born in the cloud back in the late 1980ies. They just had not invented the cloud yet.

Use your brain, think out of the box and be surprised.