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.
In this case, I’ll talk about Entity Lists, but the same logic applies to Entity Forms and Web Form Steps.
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.
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…
[…] post Where’s That Dynamics 365 Portals Code? – Part 4 appeared first on Engineered […]
Can you please give more details on “Web file” option? As far as I understand, if web file is not attached to specific page, it has no URL path. to add in script tag. At least it siteroot/webfiileurl.js not working for me.
Web Files should be attached to a specific page. In the case of JS files, it doesn’t really matter which one – often we’ll attach it to the home page, which results in the URL you mentioned above.