When I add the above line to the internal/embedded JavaScript the text “WORKED” appears however when I select the preview tab in the designer after adding file:/// or http:// referenced remote JavaScript it doesn’t work and “NOT SET” is displayed.
The remote JavaScript was configured as below.
Connect did show a read only copy of the remote JavaScript when I double clicked after setting this up using http:// but not with the file:/// URL (the configure dialogue just popped up again in this case) so I’m not sure if that means it can’t read or access the file for some reason? I tried opening Connect using “Run as administrator” in case this was a file permission issue but this made no difference.
Any guidance or help would be much appreciated, thanks!
I am not entirely sure I understood the question, but the approach you are trying to take is only applicable to a Web context and will work fine there. The Data model is not accessible from the script in the JavaScript folder.
In the Print Context(as your screenshot suggests), you should use the Scripts pane to add scripts for controlling behaviour of elements on the page.
In your example, I would add a script which targets the #testremote ID and use the following script:
results.html(“WORKED”);
or even:
results.replaceWith(“WORKED”);
If you are going to use the same scripts across templates, then you could export scripts by right-clicking on the script in the Script pane and clicking on Export and save them to disk . You Can re-import the scripts by right clicking anywhere in the Scripts Pane and select “Import”.
Thanks for the reply I’m a little confused though as when using the print context the report is constructed using HTML and the document object is definitely accessible when I create an internal JavaScript file.
As per screenshot below I’ve added an internal JavaScript file with the same code
to manipulate the DOM and this works fine (see below.) Is it just remote JavaScript that can’t access DOM objects when using a print context?
I’ve been using mostly Scripts (via the scripts pane) to build the report templates as you’ve suggested but we have a lot of templates and there’s still some common JavaScript in internal JavaScript files. The team here is keen that I investigate a mechanism to remotely reference these files to prevent duplication of code.
Scripts in the Scripts panel are cached in the sense that they are compiled only once.
Scripts in the JavaScripts folder are not cached in any way. The browser does not know they exist until the moment they are executed, which happens after the scripts in the Scripts panel have been executed.
The main difference between the two types of scripts is the runtime environment. Scripts in the JavaScripts folder run in the scope of the browser, so they have direct access to the browser but they cannot access data records (unless the record data is present in the DOM) and they cannot use the “sort of jQuery but not really” Connect API. Scripts in the Scripts panel run in an isolated environment, have direct access to data records, and can only access the browser through the Connect API.
We have no control over scripts that run in the scope of the browser, so we don’t know in what way they have modified the DOM. To revert the effects of these types of scripts we maintain and restore a deep copy of the node. For most templates (there are exceptions) copying and restoring takes a relatively long time, which means the output process (assuming multiple records) will be noticeably slower when at least one script from the JavaScripts folder is included in the section.
Scripts residing in the JavaScripts folder should be used as ‘client side’ scripts for web pages. Typically these are used to add interaction to web pages and COTG forms. For example show/hide elements based on user interaction in the browser/app. As they run ‘client side’ they do not have access to the Data Model.
Scripts residing in Scripts panel can be considered as ‘server side’ scripts and apply to all context types (e.g. web, print, email). They are executed when the document is created by the Merge Engine, therefore they have access to the Data Model.
Migrating the scripts to an entry in the JavaScripts folder (local or remote) will not help in this case.
Thanks again Rod for the clarification and the additional information
I was aware of the two types of scripts and the behaviour/restrictions of both in terms of access to the data model and the HTML DOM model. I’m aware of the order or execution and that the binding of data takes place using scripts defined in the scripts pane and also that script pane scripts can’t directly access the HTML DOM. I understand that JavaScript in the resources pane JavaScript folder runs after the data has been bound and any replacement tokens have been substituted by script pane scripts but had thought in the print context it was an option to access and manipulate the HTML DOM at this point.
I was not aware of any limitations for context types (web, print email etc.) for the “client side” scripts as the non-remote “client side” scripts seem to always work even in the print context. It’s only when I move non-remote “client side” JavaScript files to remote scripts that it doesn’t work. We depend on “client side” JavaScript to run after binding at the last minute for some report formatting which we use as workarounds in graphs to update line thickness and other features not supported natively in the designer’s implementation of AmCharts. I have however been asked by the team to investigate whether we can move more of the formatting into external JavaScript files to allow more of this to be held cross report for code reuse and to remove duplication. I understand this is highly irregular but I must demonstrate the potential issues and show an example of both approaches it will also help me understand the implications fully myself going through the motions of a POC for this. I hadn’t noticed any significant performance issues with the templates using this technique but as you’ve stated there is a potential issue with this that’s good to know and is a good argument against this approach.
I’m however perhaps a little more confused now as I’m seeing the opposite behaviour to what you’re describing, although we don’t use a web context I created a test report using a web context and the “client side” scripts don’t work at all in the web context even with non-remote JavaScript files and the small example posted earlier won’t allow any updates to the HTML DOM/document object.
I’m not clear why the non-remote scripts in the JavaScript folder work but the remote scripts don’t. I’m not sure what you meant by a “deep restore”, does this undo all the changes to the html body made by these scripts and does a “deep restore” of the body element take place only in the print context and only for remote JavaScript? That would perhaps explain what I’m seeing.
Also to clarify I’m not trying to migrate any Script in the scripts panel to scripts in the JavaScript folder. I’m trying to pull out and migrate non-remote “Client side” scripts from the JavaScript folder and reference these as remote JavaScripts to avoid duplication.
Am I perhaps missing a piece of the puzzle or making a false assumption somewhere in all of this? Are you saying in a print context although it all works as expected and we can manipulate the DOM we should never use “client side” JavaScript in the JavaScript folder? We’ve queued up and pushed thousands of reports through the workflow server with a complex workflow which pulls in multiple report templates which use “client side” scripts to further manipulate the HTML DOM after the script pane scripts have executed, we then combine these reports into PDFs for printing using this technique and never had a single issue with it.
We only use the print context and the only issue we appear to have is that non-remote “client side” JavaScript works but the remote “client side” scripts don’t.
Apologies for the lengthy response I hope it’s a little clearer! Thanks again
The internal JS will take advantage of the internal Connect Server; whereas the external JS will need an external webserver (CDN) to serve this ressource back to the template when the Connect Server requests it. In addition, this approach may dramatically downgrade performance and support for this is very minimal in the Print context.
I recommend the following two links for more details on how to use external JS:
Thanks We were hoping to use file:/// schema requests for these NOT http:// removing the need for a web server and I’d imagine it would be slightly faster too.
I know that remote stylesheets support this as do <img> tags and snippets also support file:/// schema requests too. It might help illustrate this if I give you a few examples I have working already:
Snippet to load shared header:
var mysnippet = loadhtml('file:///C:/TFS/PPConnect/ReportTemplates/resources/header.html');
results.replaceWith(mysnippet);
To get this working I simply replaced the remote http:// url with a file schema url, this let’s us hold external snippets of html, logos, and stylesheets as external files and a web server is not required.
The point of my original question was that this functionality doesn’t appear to work for remote JavaScript files(for the test JavaScript example I supplied anyway) even when served from a web server(I’ve setup and tested this with IIS Express).
We don’t want to serve this from a web server, instead we want to pull this directly from the local file system as we’ve managed to do this with other common cross report files by using a file URI. Do you know if this is possible?
I’m a little confused though as when using the print context the report is constructed using HTML and the document object is definitely accessible when I create an internal JavaScript file.
