In my last post in the series on all the different places to look for Dynamics 365 Portals code, I will discuss our best practices.

Many of these may seem like no-brainer standard software development practices, but too often we see that since Dynamics 365 Portals projects are done right in Dynamics, development best practices seem to be forgotten.

On a Web Page vs an Entity List

In this case, I’ll talk about Entity Lists, but the same logic applies to Entity Forms and Web Form Steps.

People often wonder if they should put their custom JavaScript in the attribute on the Entity List or on the Web Page. While in general both will provide similar functionality (although the script might end up in a different place on the page, which may mean it could really matter in rare circumstances), I consider what the purpose of the script is doing, and whether it is interacting with other parts of the page, or just the Entity List. I also consider whether the Entity List is used on multiple pages, and if the script applies in all the different places the list is going to be used.

If the script is interacting with other parts of the page (for example, with markup that appears in the Copy of the web page), then to me there is a dependency on the web page, and the script should live there.

If the Entity List is used in multiple places, and the script applies to all of those places, generally I’d put the script in the Entity List, to avoid duplicate code.

Use Web Template to Avoid Duplicate Code

While we’re on the topic of duplicate code, I believe that copying and pasting code, instead of storing in a central place and referencing it, is one of the worst things a developer can do. All you’re doing is creating a maintenance nightmare. But of course, you all agree with me, so I don’t need to keep talking about that…

Web Templates are a great tool to avoid duplicate code. Whenever possible, put code that is used in multiple places into Web Templates and include it where you need it. This can be useful when you have the same JavaScript that needs to go on multiple Entity Forms – use the include Liquid keyword in the Custom JavaScript attribute to reference a single Web Template that contains the JavaScript. That way, if it needs to change, you only have to change it in one place.

The Various Web Page Attributes

When it comes to a web page, there are a number of different attributes that can contain code – the most common include Copy, Custom JavaScript and Custom CSS. While it is perfectly possible to put JavaScript and CSS within the Copy attribute, I prefer them to be in the Custom attributes meant specifically for that purpose. I find it keeps everything much cleaner.

Large Site-specific JavaScript Library

If you’re working on a Portals implementation that requires the development of a lot of JavaScript, and that JavaScript needs to be included on every page, you’ve got a few option:

• Include the JavaScript in the Footer Web Template: while this is technically an option, I don’t recommend it. If you’ve got a large library, this will make the Footer template unwieldy. If you must include the JavaScript in a Web Template, at least check out the next option.
• Create a separate Web Template for the JavaScript, and include it in the Footer: this way at least the JavaScript is in its own Web Template. However, it still requires that the browser downloads the entire library each time it requests a page on the website.
• Upload the JavaScript as a Web File, and reference the .js file via a <script> tag inclusion: this means you can’t directly edit the file in Dynamics 365, but the browser can now cache the file, and doesn’t need to request it each time it loads a page. This is the preferred method, but I know it’s not as convenient when you can’t make quick changes to your code without uploading a new file.