Script Libraries: Reusing Client Side Code Between Screens

1 minute read time.

It has always been possible in Sage CRM to share client side code between screens. In Sage CRM we could do this by using a shared external script library.

For example if we wanted a set of business rules to be available in both the PersonBoxLong screen and the PersonBoxDedupe screen then we could add the following HTML to the custom content box of each screen

[code language="html"]
<script src="..\\custompages/personrules.js">
</script>
[/code]

The path used assumes that the shared file 'personrules.js' exists in the custompages folder underneath the systems web folder WWWRoot.

JavaScript is used through out the Sage CRM interface but this JavaScript code is not wrapped up in the eware.dll but instead the code is defined in external js files which are deployed to the client.

There is a folder under the WWWRoot, called js.

The files which are included here are deployed automatically to the client.

You can see this if you view the source of any Sage CRM screen.

References to the files are automatically added to each page header including dynamic workflow pages, ASP pages and .NET dll generated pages for Custom Entities.

We can create our own Custom Pages and have these added automatically to all screens.

There is a custom folder which is designed to hold our custom scripts.

These scripts are then available when ever we need them. They are included into the page headers just like the core CRM js files.

You can see in the image above I have added a file called 'companyrules.js'. The reference to it is shown in the image below.

I will cover the design of script files in another article.

Parents
  • This is a very neat trick, and one that I thought would come in handy for a scenario I'm working on, but there seems to be a timing issue with the rendering of the page & loading of the custom script libraries when it comes to workflow javascript conditions.

    I've created a custom script library with a function defined in a custom namespace, as described in a related article. From the screen in question, I can see that the library is loaded, and using the Chrome console I can test the function I wrote to make sure it behaves as desired. When I add my function to a workflow rule javascript condition field, however, I get an error essentially saying that my namespace is not defined, even though on the resulting page (displaying that error message in red), I can open the console and call up my function without issue.

    Is there some way to make sure the workflow javascript condition only executes after all libraries are loaded? (attempting to call $(document).ready was unsuccessful) Or is this an area where we can't use our custom libraries?

Comment
  • This is a very neat trick, and one that I thought would come in handy for a scenario I'm working on, but there seems to be a timing issue with the rendering of the page & loading of the custom script libraries when it comes to workflow javascript conditions.

    I've created a custom script library with a function defined in a custom namespace, as described in a related article. From the screen in question, I can see that the library is loaded, and using the Chrome console I can test the function I wrote to make sure it behaves as desired. When I add my function to a workflow rule javascript condition field, however, I get an error essentially saying that my namespace is not defined, even though on the resulting page (displaying that error message in red), I can open the console and call up my function without issue.

    Is there some way to make sure the workflow javascript condition only executes after all libraries are loaded? (attempting to call $(document).ready was unsuccessful) Or is this an area where we can't use our custom libraries?

Children
No Data