[dev] Javascript depency loading

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> I already had a short discussion with Michael Rubinsky on IRC two  
>>> weeks ago, and two events reminded me about it: The necessary  
>>> fixes to correctly load tooltips.js and the required prototype.js,  
>>> and Ajaxian mentioning LABjs (http://labjs.com/description.html)  
>>> again.
>>>
>>> Here's the IRC log:
>>>
>>> (18:04:12) yunosh: is it worth to use a depency loader like  
>>> http://feedproxy.google.com/~r/ajaxian/~3/Vq4qcO7idLI/labjs-simple-abstraction-for-loading-dependencies-correctly to solve the js file loading order  
>>> issues?
>>> (18:17:21) mrubinsk: yunosh: looks interesting, though I guess  
>>> we'd need to test to see if it would work well with pages that  
>>> might have had the same js file added via Horde::addScriptFile()  
>>> in other places....or were you talking as a general solution to  
>>> implement within Horde::addScriptFile()?
>>> (18:18:57) yunosh: rather something to replace addScriptFile(), or  
>>> actually something that's build from addScriptFile() instead of  
>>> plain <script> writing. That would require dependency support on  
>>> the php side too of course
>>> (18:19:03) yunosh: just brainstorming here
>>> (18:20:47) mrubinsk: sounds like it's worth looking into more  
>>> thoroughly then...
>>> (18:22:05) yunosh: i'm not sure if it's adding more overhead than  
>>> necessary for things that we can sort out manually with a bit of  
>>> patience
>>> (18:29:09) mrubinsk: yea, it's also not clear how well it would  
>>> behave with adding scripts in multiple paces in the code
>>> (18:29:56) mrubinsk: at least from my cursory look :)
>>>
>>> I want to re-start this discussion because such a solution could  
>>> not only help us solving the dependeny issues, but also speed up  
>>> page loading. Beside that, we could load more script files  
>>> directly from JS code on-demand. The latter would keep the  
>>> after-loaded scripts from using our JS cache, but it might be  
>>> worth for some rarely used scripts, and it's an added bonus anyway.
>>
>> My thoughts:
>> 1.) There is (should be) no dependency issues.  *Everything*  
>> requires prototype.js to be loaded first.  After that, it doesn't  
>> matter the order the files are included.  If there is, then the  
>> script is broken and needs to be fixed (all initialization should  
>> be done in a domload event handler - this eliminates all issues  
>> with dependencies).
>
> This is not quite true. There is also date.js which is required in  
> Kronolith, and soon by the date picker widget, but nothing else  
> (yet). date.js requires a locale js file to be loaded first. That  
> means that any place that is going to use the date picker must take  
> care of loading 3 different js files in the correct order, including  
> a variable file name that's going to be injected from the outside.
> And I can imagine that we are going to load more js libraries in the  
> future that might be the base for other js files. Think of any  
> widget depending on scripty. We don't want to load scripty on every  
> page.
> We *do* have dependency issues and we have to solve them somewhere.  
> This could of course completely be done in PHP, LABjs or similar is  
> just one possible solution.

A possible solution, and one I am looking at re: Horde_Editor, is to  
bundle the more complex javascript elements in a framework package and  
then have the package deal with the dependencies.  This has the extra  
advantage of allowing us to upgrade a package correctly if the  
javascript components are updated.

This will require us to write horde-specific PEAR roles to correctly  
install this javascript.  Don't know if this is feasible or not.

http://pear.php.net/manual/en/guide.migrating.customroles.defining.php

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]