A lot of us still have a ton of C/AL code sitting around in existing databases that sooner or later will have to be moved into AL. A lot of us also have a ton of AL code using DotNet that we want to be able to run in Microsoft’s cloud (that is: not on-prem). And I guess most of us don’t want to maintain a DotNet-less and DotNet-ful versions of our code.
Sooner or later, you’ll want all of DotNet out of your AL. Even if you are a seasoned .NET developer, you’ll want all DotNet out of AL.
Anyway, when you need to replace DotNet, what options do you have? Let’s take a look at all possible paths.
Thanks to everyone who watched my live stream today! The audience wasn’t big, but it’s a very narrow topic, not of broad interest. Still, I am glad I got a few interesting questions that actually introduced my future topics quite nicely.
You can find the recording here:
As promised, I have published the GetImageResource.js file on my GitHub. You can find it here:
Thanks to everyone who attended my live blog yesterday, and to everyone who subscribed. It was so encouraging to see that you like this idea.
As announced yesterday, my live blog will run on a fixed schedule – every Friday, at 14:00 CET (8:00 AM EST) I’ll get online to present a topic and discuss it live with you. This is the schedule for the next two Fridays:
November 20: Migrating Control Add-ins from C/SIDE to AL
This is going to be a live coding session. I’ll take a working control add-in developed in a mish-mash of tools we used to develop them back in the stone age, and migrate all that into AL. I’ll present two viable approaches for this, that I’ll call a “white box approach” and a “black box approach”.
While doing this, I’ll also discuss what can be done, what can’t be done, and things you want to watch out for while performing the migration.
November 27: Fun with Interfaces
Again, a mostly live coding session. I’ll present AL interface type, what it’s good for, and how to use it. Of course, I’ll address the usage through enum type, but I’ll also talk a lot about other use cases. Interfaces allow us to fix some old and long-standing anti-patterns, and introduce some nice new patterns, and you can expect me talking about that, too.
It was great to see that – when I asked about what topics you’d like to see me cover – there were both interfaces and design patterns in AL. It tells me we are on the same page here.
December: You tell me
I have no firm plan for December yet. I actually want you folks to have most of say in what my live blog will be about. Yesterday, you gave me some ideas and today I want to let you choose.
In the poll below, select up to two topics you’d like me to cover in the first two live slots in December.
[poll id=”2″]
The poll runs until noon on November 19th, the top two answers will be my topics for December 4 and 11.
What topics do I have in mind?
Other than the topics you (will/have) suggest(ed), I have a few topics of my own that I’d like to bring some attention to:
Communicating between AL and JavaScript: this is something that every control add-in author encounters, and the documentation is practically non-existent. Usually, I cover this to great depth in my control add-in trainings and I’ve talked a lot about this in my TechDays sessions, but still I want it properly documented here as well. This has almost been my very first topic for my live blog, but then I changed my mind. Still, I may cheat a bit – it’s very likely I actually pick this for my December 4th session, and push your suggestions a week further. Let’s see.
Musings around transaction control in AL. We’ve had AssertError Error('') for a long time, and now we don’t (really) have it anymore. We need to fall back to (or simply keep relying on) if Codeunit.Run(). But this is very limited in terms what and how we pass state between caller and callee. This will be a “let’s code and theorize together” kind of session, more about discussing what we have and where we would like to go from here and why, than presenting actual “how to this or that”.
TypeScript vs JavaScript when developing control add-ins. Could be an interesting topic, I don’t know. I have been coding in JavaScript since 1996, practically from the beginning. Obviously, I got used to all of its quirks. TypeScript didn’t at first seem to convince me, but recently I’ve written far more TypeScript than JavaScript. Let me know if this is something you want us to discuss. This could be a Q&A session with some code.
What happens to your JavaScript code when browsers run it. This would be a deep dive into browser runtime, how it processes your JavaScript, how it runs it. Here, I’d address some misconceptions people have about it. I think this could be a nice session to cover an important aspect of the web client runtime. It’s crucial to understand how things work to be able to pull the maximum out of them.
Musings around event infrastructure in AL and BC runtime. Personally, I’ve never been totally convinced that the events – the way they work – are the best we could possibly have. Don’t get me wrong – they are amazing at allowing us to build loosely-coupled architectures and to seamlessly plug in our code into other people’s code. But there is much more they could be if Microsoft wanted to take an extra step. I’d love to discuss this topic with you. Who knows, maybe we manage to convince Microsoft that we need a bit more push here. Or maybe you manage to convince me that I am getting it all wrong. Who knows.
Let me know in the comments what other topics you’d like me to cover, and also what you think of these topics I suggest here. Enjoy the weekend, and see you next Friday!
You’ve noticed that I’ve been absent for a long time. No posts, no activity. Well, blogging takes time, and I am a sort of a perfectionist. Writing posts sometimes takes hours, there have been posts that took me days. Let me not mention how many articles sit unfinished. Most of them make no sense at all to complete anymore.
I was thinking of video blogging. Eric Hougaard has a pretty cool video blog, and he actually inspired me to start thinking in that direction. But having created dozens of videos myself, and being perfectionist and all, creating videos takes a lot more time than writing posts.
So, I’ve decided to try something else: live blogging. Yeah, right, I always get on a train five years after it takes off, but better late than never, they say.
To make the long story short, today at 15:30 CET (that’s 3:30 PM EST) I kick off.
The place you want to be is https://vjeko.com/live or you can simply scan the QR code below.
Good. If you want to know how this new live blog will work, I invite you to join me today, or to watch the recording afterwards. No spoilers, no trailers. Just pure BC fun (Sheldon Cooper style 🤣)
The community often criticizes Microsoft for adding new platform features only when Microsoft needed them. Well, it has been a bit too harsh – Microsoft did add improvements in other situations, too. But still, if you compare it to other Microsoft’s languages like TypeScript or C#, the AL language isn’t really advancing.
Looking back at C/AL, the AL language has really brought a lot of improvements. We have native JSON types, HTTP API, interfaces, overloads, and a lot more. But still, the overall change of the AL language was minor improvement, rather than a real evolution that transition to VS Code could have allowed.
Here’s the list of top five things I’d absolutely love to see in AL. And I have strong reasons to believe that all of them would be fairly easy to implement for Microsoft. Let’s get started.
I’ve never truly understood why we could explicitly commit a transaction, but we could only implicitly roll one back. There is a universe of difference between throwing an error (and ending the call stack), and rolling back (and continuing execution).
There was always a way to roll back and go on, sure. Wrap the entire thing in a if Codeunit.Run() block, throw an error as the last thing inside that codeunit, and there you go. Problem solved. Well, not quite.
Long time no see, but that’s how it gets every now and then, I guess… Anyway, I am still alive, still kicking, just don’t get to blog as much as I’d hope for, it’s work, and life and universe and everything.
So, I am back with not a typical “Vjeko” post, just a simple AL opinion piece. A tip, without a trick.
One of the problems we’ve all suffered from in the old days of C/AL (who remembers that still, anyway) was inability to define real text constants. One thing we all avoided was using hardcoded Text literals, like this:
It was not only about the sheer scariness of using Text literals in C/AL, stuff that if left unchecked could cause process issues, something nobody in the ERP world (especially those on the business end of it) likes. Arguably, the worst thing about this kind of code was total lack of reusability. If you had to reuse the literal, you would have to write it again:
Yeah, the mismatch (or typo, whatever you prefer) is intentional to prove my point. You could mistype it, or somebody may decide to change it and then forget to change it in all places, or… stuff happens, you know. It was no good.
There were no constants, and it sucked.
Yeah, yeah, there *were* TextConst constants, but that’s not it. The moment you did this:
… somebody could come in and “fix” it like this:
And there was no way for you to prevent them. There goes your discoverable extension, things break up and your users start yelling your way.
Back in those pre-historic days, I’ve seen people work around this problem like this:
The “constant” is coded in one place, other place call the wrapper function, and world goes on. That was the way to do it in C/AL, truly.
Fast forward back to present. I’ve got myself in the middle of refactoring a chunk of code migrated from C/AL to AL a while ago. It’s full of “pluggable” things that identify themselves to various discoverers, and it’s full of “constants” coded with this function-that-returns-a-hardcoded-literal pattern.
While this worked miracles in C/AL, in AL we actually have a far better way to handle this. Labels. Yeah, fells like I am discovering hot water or sliced bread or something, but please, for the record, don’t do this:
Instead, do this:
If you set the Locked property to true, you are making sure nobody inadvertently translates it, and you keep it a bit cleaner. This is especially true if you have multiple constants – listing them in your var block will be much cleaner than creating a function a piece.
Here endeth the lesson. No rocket science, just an easy one to document my train of thoughts for posterity. Everyone is entitled to my opinion, after all 😁
You might have noticed that I had some problems with pictures on this blog. Some posts simply didn’t show any of them, and I’ve got quite some reports that they aren’t working. Unfortunately, I’ve been so busy recently that I really didn’t have time to look into it.
A few days ago, a regular visitor of this blog that goes by the name of Bjarki took time to figure out what’s going on. He posted a comment about his finding, and that’s truly amazing. Thanks, Bjarki! 😀
Apparently, when I moved my blog to a new server, for some reason, some of the pictures got referenced with the staging URL and that URL remained in my blog database. Bjarki’s hint explained to me that the fix may be simpler than I feared. I did a search and replace (using the amazing Velvet Blues Update URLs plugin for WordPress) and voila!
I hope I get time soon to do other stuff on my blog, I know you are waiting for the continuation of the control add-ins supercharged series. It’s coming, it really is.
True, there was no episode 1, not on this blog. But if Star Wars can start with episode 4, I don’t see why can’t I start with episode 2. Especially when Waldo has already written episode 1.
So yes – apparently, up until a few minutes ago – with the new theme my blog has been sporting for a while, it was impossible to search my blog. Somehow, for some reason, the theme I applied didn’t expose the search button in the header, as most modern themes do, and I didn’t notice.
But Twitter did notice.
And then Waldo fixed it:
Well, in any case, it’s there now. Not really in the most prominent place (it’s right in the footer, just scroll down) but for now, take it as is. When I have more time to work on my blog and blog about serious things, I may move this search feature around a bit.
I’ve been absent for a while – sometimes it’s difficult to find time for blogging even when I want it. Anyway… here’s the last post in the introductory series of posts that explain my NAV TechDays 2019 demos. In this code example, I explain the difference between typical development and production build configurations, and I show how to configure gulp accordingly.
