Feature #16900

Use static method to integrate prototype or script.aculo.us framework

Added by Oliver Hader over 14 years ago. Updated almost 13 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Sprint Focus:


Prototype javascript framework and script.aculo.us are used in several backend modules. But also frontend extensions could use these frameworks.
It could possibly happen, that there a two or more extensions which integrate on of these files by <script src="..." type="..."></script>.

To avoid this, it's requested to have a static method like


that takes care of it and stores a true value to a global variable like $GLOBALS['JSincluded']['prototype']. Now all scripts "know" that prototype.js was included and don't have to do that again.

(issue imported from #M4860)


includejslib.patch (3.54 KB) includejslib.patch Administrator Admin, 2007-01-28 17:54

Updated by Ingmar Schlecht over 14 years ago

To avoid double inclusions of libs in the Frontend, you usually just assign the same key to the array item in the $GLOBALS['TSFE']->additionalHeaderData array.

For example:
$GLOBALS['TSFE']->additionalHeaderData['prototypeJS'] = '<script type="text/javascript" src="prototype.js"></script>';

In the Backend the same looks like this:
$this->doc->JScodeArray['prototypeJS'] = '<script type="text/javascript" src="prototype.js"></script>';

Given people are always using the same array key for the same library (e.g. 'prototypeJS'), this is already a pretty well working solution to avoid double inclusion of JS libs.

I'm against introducing a like t3lib_div::integrateJSprototype() because it's too specific. But in the long run, a good solution would maybe be a new function t3lib_div::integrateJSlib($libName) that can handle keys such as "scriptaculous.effects" or "prototype" and also resolves dependencies like automatically including prototype when scriptaculous should be included.

Bottomline is: In the short run, settling on a standardized array keys of the already in place methods to avoid double inclusions is enough, but in the long run a general JSlib inclusion function should be built.



Updated by Benni Mack over 14 years ago

Hey Ingmar,

actually, I would include this function "t3lib_div::integrateJSlib($libName)" right now, and have simple / no dependencies for it, so people start using the function and do not try to do their own thing. Later on we can decide how important it is to have a complete dependency structure etc etc.


Updated by Ingmar Schlecht over 14 years ago

Cool, would, be great if you could write a patch.

I just re-thought the name, and I think includeJSlib() seems good, what do you think?



Updated by Benni Mack over 14 years ago

sure, I could do that. only one question remains. How can I find the path to the libraries? I mean, in t3lib I do not define the "backPath", also I need to find out if we're in the frontend or backend. Maybe we need two params for this:
($libName, $backPath)
But maybe I don't get the whole picture here and there is an easier way to do...


Updated by Benni Mack over 14 years ago

Btw... will this go in 4.1 or 4.2 (in terms of work priority for me).

Personally I would love to see this in 4.1 so ext-developers will use it right away.


Updated by Ingmar Schlecht over 14 years ago

Hi Benjamin,

I'd be happy to let this into 4.1, yet I haven't got time to work out good solutions for problems like the one you mentioned ($backPath, etc.).

If you can solve those on your own or by asking some mailing lists, I guess we'll be able to commit this before RC1.


BTW: Was it a right decision to put JSON and prototype into typo3/contrib/ instead of t3lib/contrib/? I'm just thinking... because things that are shared between the backend and frontend should better be placed in t3lib/


Updated by Benni Mack over 14 years ago

Hey Ingmar,
I don't know for sure. But a couple of months ago, the prototype.js file was moved from t3lib/ to typo3/ - there had to be a reason for this. I don't know it though. About the path problem.
  • If we're in FE, we can find out if a $GLOBALS["FE"] exists if we're in FE or BE
  • In BE, we need to have the template-file $this->doc available so here's the idea.

=== t3lib_div ===
function includeJSlib($libName, $backPath) {
// return <script>-tag, maybe some dependencies or so.

=== template.php (for Backend Use) ===
function includeJSlib($libName) {
$this->doc->JScodeArray[$libName] = t3lib_div::includeJSlib($libName, $this->backPath);

backend users do:

frontend users do:
$GLOBALS['TSFE']->additionalHeaderData["prototype"] = t3lib_div::includeJSlib("prototype", $pathToIt);


Updated by Benni Mack over 14 years ago

ok. some more ideas for the FE-user part. I'm gonna prepare a patch the next couple of days.


Updated by Benni Mack over 14 years ago

I have a patch, but there were some problems - The following is not working in the template.php:
$this->JScodeArray['prototypeJS'] = '<script type="text/javascript" src="prototype.js"></script>';

a) the JScodeArray is added AFTER the inline JS code. Actually this wouldn't be a big problem, although it means that is some functions are called before the Array-files are included, they can't be used at all.
b) The JScodeArray get's wrapped in script tags when displaying the page
$this->wrapScriptTags(implode("\n", $this->JScodeArray))

So I introduced a new variable (array), called $JSlibArray. It gets inserted before all the other JS code and is nice for including external JS files.


Updated by Benni Mack about 14 years ago

Was there any news on this integration?
Right now I have this problem while writing a new feature for the backend: How do I know if the prototype library is already included?
Would be good to have a solution soon. Otherwise I gotta do this:
if (!strpos($doc->JScode, 'prototype.js')) ... // include

the other sad thing is (as posted above) that $doc->JScodeArray has this prevention mechanism (double inclusion) already but get's inserted too late (after the inline JS).

Also available in: Atom PDF