Feature #16900

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

Added by Oliver Hader over 12 years ago. Updated over 11 years ago.

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


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 View (3.54 KB) Administrator Admin, 2007-01-28 17:54


#1 Updated by Ingmar Schlecht over 12 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.


#2 Updated by Benni Mack over 12 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.

#3 Updated by Ingmar Schlecht over 12 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?


#4 Updated by Benni Mack over 12 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...

#5 Updated by Benni Mack over 12 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.

#6 Updated by Ingmar Schlecht over 12 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/

#7 Updated by Benni Mack over 12 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);

#8 Updated by Benni Mack over 12 years ago

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

#9 Updated by Benni Mack over 12 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.

#10 Updated by Benni Mack over 12 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