Not using drupal_add_js to add javascript

My current direction of thinking is to add a theme function called by the view op on hook_nodeapi that adds noncachable page elements to the viewing of assets. Initially it would include things like drupal_add_js calls though it could be extended to other areas.

I'm working on a project this coming week that could really benefit from this so I'll roll a patch when I get to that point in the project and take it for a test spin.

It's going to be another week. My development machine is in the shop.. doh.

@wmostrey - here's my proposed solution.

First, add another op to hook_asset_formatter called nocache. This is where operations that can't be cached can be placed.

Then, in hook_nodeapi with the op view we call something like

  module_invoke($module, 'asset_formatter', 'nocache', $asset, $attr);

This would allow other modules to extend and work on assets in a non-cached manner. In that op there could be a theme call that can be attached to the rendered node and then displayed. There could be a call to drupal_add_js or drupal_add_css.

Plus, other modules can extend what is already there. I would use it to implement thickbox. It could be used to move lightbox support into a separate module.

Thoughts before I start coding this?

So, assets can be attached to nodes and blocks. I'm guessing this applies to any textfield we can have in the system, right? Anywhere?

I have a feeling this is frowned upon but what about doing something like http://www.php.net/manual/en/function.override-function.php#50821 on check_markup and somehow detecting what assets are thrown and acting on them. It would be nice if check_markup allowed a partially cached mode.

This would then work on every text field in the system that accepted input formats. Any thoughts on other ways to expand this beyond just nodes? Even if there was an easy way to detect when check_markup is fired and getting it's input parameters.

The more I look into this the more we may not be able to do it for every textfield. For nodes and comments it wouldn't be to hard. We may even be able to get it into blocks. But, input formats can be used everywhere and we would end up leaving it off somewhere in some custom module.

Maybe we need to look at different approach. Something in the javascript. Time to go brush up on that. I'm open to any ideas at all. No matter how crazy. I've had some weird issues because of this problem.

Alternate thought. Let's try and do something that works for filtered locations. What about a design pattern that we could reuse for the filters. For example, let's take the swfobject include code for flv videos. What if we include a short script that checks if swfobject is loaded and if it isn't loads it. This would have it loaded only once. Thoughts?

This same pattern could be used for other things and even jquery.js/drupal.js.

@wmostrey - What I was thinking was instead of:

<script src="/sites/all/modules/asset/asset_bonus/swfobject/swfobject.js" type="text/javascript"/>

We insert javascript with the filter that looks something like:

var scripts = table.getElementsByTagName("script");
var swfswitch = false;
for (var i = 0; i < scripts.length; i++) {
  if (scripts[i].src == "/sites/all/modules/asset/asset_bonus/swfobject/swfobject.js") {
    swfswitch = true;
  }
}
if (swfswitch == false) {
  var newjs=document.createElement('script');
  newjs.type='text/javascript';
  newjs.src='/sites/all/modules/asset/asset_bonus/swfobject/swfobject.js';
  document.getElementsByTagName('head')[0].appendChild(newjs);
}

This would check for the swfobject file and only include it if it isn't already included.

This pattern of checking and only including if not there could be extended to any javascript, including core. We could include something like:

<script type="text/javascript"/>
var corejs = <?php print drupal_get_js(); ?>
var scripts = table.getElementsByTagName("script");
var swfswitch = false;
for (var i = 0; i < scripts.length; i++) {
  if (scripts[i].src == "/misc/jquery.js") {
    swfswitch = true;
  }
}
if (swfswitch == false) {
  document.getElementsByTagName('head')[0].appendChild(corejs);
}
</script>

Thoughts? It's a little extra javascript to parse through but it does conditionally including. And, it could all be done inside the same theme function that is now inserting the javascript.

In the filters code we add something like:

document.getElementsByTagName('body')[0].appendChild('what we want to insert');

This would put what we add as the last thing before the closing of the body tag. We could use this javascript to add javascript as the end of the page.

I have a feeling it's not going to be quite that easy but this is the general concept. I'll try to write something and test out this theory over the next few days.

An update... I'm partially there with this fix. I've got it working and tested in IE6 and Firefox on both PC and Mac. My trouble browser is safari. The current code works for blocks in garland, too. I want to do more browser testing and work out the Safari bug. Not using a js library has really brought out the quirks between browsers with JavaScript :(.

Here is a patch tested in IE6, Firefox (mac and pc), and Safari 3 that works for video in the node area and a sidebar block in garland.

Writing this is really giving me an appreciation for javascript libraries that deal with browser issues.

In some browsers when you add something to the DOM with javascript there is a slight delay before it's added and some browsers have javascript as a single thread so I used setTimeout to deal with that. It lets items be loaded in the interval.

Feedback here is much appreciated. I'm sure this can be improved upon.

This takes the same technique and applies it to asset bonus audio as well as video players. The idea is to only load the external javascript files once. This works in blocks and in body content.

Thoughts?

With this I'm not getting incorrectly shaped or odd issues with the objects anymore.

Let's try attaching that patch again.