I've never been short on complaints about the HTML composer, but this just takes the cake.

I have a javascript file to include in all my HTML reports. I want to include it at the end of my HTML, so that it gets executed after the content above has been parsed. I do not want the code to live within the window_onload function.

I included the script reference directly above the closing body tag, like so

<script type="text/javascript" src="/ibi_html/javaassist/some-script.js"></script>
</body>
 

but when I save, close, and re-open in the GUI it gets trashed and converted to this

<SCRIPT id=ITEM1 type=text/javascript src="htmlpathsub/javaassist/some-script.js" UserSuppliedFullPath="1"></SCRIPT>
 

and included at a seemingly-random spot in the middle of the HTML, which means it is not executed after page content is parsed and the functionality breaks.

Is there anything at all I can do to prevent this? This behaviour means I can't trust anyone to open my HTML report in the GUI unless they know AND remember to undo this mess before saving.

Why any developer would ever think this was a good idea is completely beyond me.

This message has been edited. Last edited by: <Kathryn Henning>,

The parsing of HTML is not an exact science, different browsers will behave differently. Basically you should never rely on a piece of javascript being run at particular point in time because of its position in the code. Thats what the unload type methods are for.

So I do not see a particular problem with the Javascript to be moved to a different location.

Hi Tom

If you import the JS file correctly, the HTML Composer will give it and and id = ITEM1 and set it up the way you have observed. You can open a case and maybe we can work around the issue depending on what you are trying to do.. You can ask that Barry gets assigned the case.

Thanks Barry

There are a number of reasons for including JavaScript references at the very end of an HTML document, including Yahoo's performance advice.

I'm attempting to introduce a mechanism where non-web developers can have a single line of code to include at a specific place and not have to worry about it. It would be possible for my code to be added to the window_onload function but it's more likely to go wrong when edited by someone who doesn't know what they're doing. My main aim is to override the form.onsubmit event after it has originally been defined. I can't completely overwrite the event handler, as the original handler must be executed as part of mine. This means my code has to be executed after the page has been parsed including the <form> element which includes an onsubmit handler.

I can understand why the HTML composer would handle scripts imported through its GUI in a particular way, but for it to be shredding HTML that I have manually added is just crazy. It violates the Principal of Least Astonishment.

Two comments:

1) HTML Composer currently adds a script block after the end body tag if you have a Calendar Control

<SCRIPT id=IBI_loadcalendar type=text/javascript>
if(ibigblInitInfo.testOptions(rltdyncalendar)){
     setDateRange();
     setupDocCalendars();
}</SCRIPT>

<SCRIPT id=IBI_loader type=text/javascript>
doBeforeLoad();
</SCRIPT>

From what I've read on the internet, this really shouldn't be after the end body tag, but just before it.

2) Adding my own script tags

I add three script tags via the text editor:

<script type="text/javascript" src="/approot/web/jquery-latest-min.js"></script>
<script type="text/javascript" src="/approot/web/jquery-ui-latest-custom-min.js"></script>
<script type="text/javascript" src="/approot/web/cppib-util.js"></script>

Save the page after making a tiny change via the GUI and the lines get modified to this:

<SCRIPT id=ITEM3 type=text/javascript rtFileName="/approot/web/jquery-latest-min.js"></SCRIPT>

<SCRIPT id=ITEM4 type=text/javascript rtFileName="/approot/web/jquery-ui-latest-custom-min.js"></SCRIPT>

<SCRIPT id=ITEM5 type=text/javascript rtFileName="/approot/web/cppib-util.js"></SCRIPT>

I then have to change "rtFileName" back to "src" (because we're at v7703 HF 5).

I've never seen "htmlpathsub"...

Try putting your script tag just before the end head tag - you shouldn't get "htmlpathsub", but you may get "rtFileName"...

I've never heard of the Principle of least astonishment - it looks like a good read.

Cheers,

In the end I had to refactor my code to deal with this behaviour. Fortunately if I add an external script resource its script tag is included at the end of the head section, after the function that I want to override has been defined.

I still think that Developer Studio is over-complicating this, and it's getting in my way more than helping. It converts my perfectly reasonable script tag into this monstrosity:

<SCRIPT style="Z-INDEX: 0" type=text/javascript src="http://myurl.js" UserSuppliedFullPath="1"></SCRIPT>

WebFOCUS is the only place I've seen capitalised HTML tags in the last 5 years, but the bigger concerns are why a script resource needs a z-index and why attribute quoting is inconsistent. Very strange.

My purpose in all of this was to alter the URL used to execute an HTML report's referenced .fex so that I could route the request through my site's proxy, acquiring an authentication token along the way if the user is authenticated (required to then pass through a Tomcat filter). However I didn't want the URL to be permanently altered, as the same location is used to get dynamic list values and my proxy doesn't handle those. I've pasted the code below in case anyone else has a similar requirement.

window_onload = function(originalOnload) {
    return function() {
        originalOnload();
	var allInputs = document.getElementsByTagName('input'), i, eachInput;
	for(i = 0; i < allInputs.length; i++) {
		eachInput = allInputs[i];
		if(eachInput.hasOwnProperty('type') && eachInput.type.toLowerCase() === 'submit') {
			eachInput.onclick = function() {
				var originalGetWFScriptName = getWFScriptName;	// returns original execute URL
				getWFScriptName = function(){return 'http://<mysite/proxy>/';};
				// reinstate original function after current execution stack completes
				setTimeout(function(originalFunc) {
					return function() {
						getWFScriptName = originalFunc;
					}
				}(originalGetWFScriptName), 0);
			};
		}
	}
    };
}(window_onload);

quote:

Originally posted by Francis Mariani:
2) Adding my own script tags

I add three script tags via the text editor:

<script type="text/javascript" src="/approot/web/jquery-latest-min.js"></script>
<script type="text/javascript" src="/approot/web/jquery-ui-latest-custom-min.js"></script>
<script type="text/javascript" src="/approot/web/cppib-util.js"></script>

Save the page after making a tiny change via the GUI and the lines get modified to this:

<SCRIPT id=ITEM3 type=text/javascript rtFileName="/approot/web/jquery-latest-min.js"></SCRIPT>

<SCRIPT id=ITEM4 type=text/javascript rtFileName="/approot/web/jquery-ui-latest-custom-min.js"></SCRIPT>

<SCRIPT id=ITEM5 type=text/javascript rtFileName="/approot/web/cppib-util.js"></SCRIPT>

I then have to change "rtFileName" back to "src" (because we're at v7703 HF 5).

That was actually a bug (in Dev Studio 7703) introduced with HF5 or something and is now fixed with HF7. This particular bug has for me resulted in many extra coffee breaks to cool off. It has gotten to the point that I postpone changes to launch-pages as long as possible, as I really don't want to. By now, I absolutely hate HTML Composter. IMHO, it has taken IBI far too long to release the fix.

Anyway, it's been fixed.

As for the OP's problem; it doesn't ring a bell, but in general it is bad form to expect that the page finished loading at the end of the HTML tags.
At the very least, at that point the browser hasn't parsed the closing body and html tags yet, meaning the DOM isn't yet complete when your script might already be referencing it.
Another issue is that IBI's code runs when the document finishes loading (they use window.onload), which happens after those closing tags have been parsed, which means it could run just after your script runs. Timings like these will differ between browsers and network latencies, but it will probably be unreliable.

I think what you're supposed to do is to wrap your code in a function and call that from IBI's onInitialUpdate() function, which by default isn't added to the local code but will be called if it exists.

Of course, if your script is entirely independent of the DOM or IBI's code, then what you do is perfectly legitimate. But then it wouldn't matter where in the document it gets called, so it probably does rely on some of that stuff.