Calling all developers! Registering javascripts... lets reuse the ones already there

As great as a trip to Oz would be, I was thinking more about the hot springs in Rotorua, NZ, or a private car on the train through Arthur’s Pass in the Southern Alps. How are flights from Sydney to Auckland / Wellington / Christchurch? :-D

$AU300 return if you book a couple of months in advance 😊

Oh you don’t know how much I want to be there! I have begged and pleaded with Lea, Mark Bowen, Victor and ExpressionEngineer to live blog it but I guess they all will be having too much fun 😉.

Am I going then???

If I am then it’s the first I’d heard about it 😊

Unfortunately I can’t go either so I won’t be able to blog about it at all I will just have to guess!

Best wishes,

Mark

Oh you don’t know how much I want to be there! I have begged and pleaded with Lea, Mark Bowen, Victor and ExpressionEngineer to live blog it but I guess they all will be having too much fun 😉.

Am I going then??? If I am then it’s the first I’d heard about it 😊 Unfortunately I can’t go either so I won’t be able to blog about it at all I will just have to guess! Best wishes, Mark

Just shouting out all the members I knew 😊

Hi all!

Leevi, I really like the way you think about these issues, excellent topic. I do however see some problems with this approach.

1) What will happen if a module adds jQuery 1.2.3 and you decide to release a module that requires some of the to-be-released jQuery 1.3? As far as I know multiple jQuery versions can’t be used at the same time. (which is probably so for most JS libs)

2) I use MooTools (and jQuery) most of the time, and one of the great things about MooTools is its Download Generator where you can create a file by only choosing the components you need, thus decreasing the file size. Someone else probably needs different components for their EE add-on… so you’ll need to include the full library.

3) Now let’s for a moment assume that EE 2.0 will include jQuery 1.2.3, and the next release EE 2.1 includes jQuery 1.3 (need to stay up to date right), we are back to problem #1.

I’d love to see EE include a JS lib for us all to use, and I like you idea of re-using scripts that are already added, but I’m not convinced it would be practical.

Food for thought…

Hey Cocoaholic,

Thanks for your input…

1) What will happen if a module adds jQuery 1.2.3 and you decide to release a module that requires some of the to-be-released jQuery 1.3? As far as I know multiple jQuery versions can’t be used at the same time. (which is probably so for most JS libs)

I’m guessing we could possibly have this issue now if two developers added their scripts in their own way. I’m not sure how to avoid this. One of my goals was to reduce the number of server requests for the same library file.

2) I use MooTools (and jQuery) most of the time, and one of the great things about MooTools is its Download Generator where you can create a file by only choosing the components you need, thus decreasing the file size. Someone else probably needs different components for their EE add-on… so you’ll need to include the full library.

The generators are great and I know jQuery has one for jQuery UI. I guess in this case you would need to change the file name to something unique and register it that way.

$this->_register_script('cocoa_module_jquery.1.3.pack.js', 'jquery');

It won’t solve the issue of having the same functions and parts of the lib requested more than once but it still allows you to check that you don’t request the script multiple times. An example of this is new custom fields that use JS. A user can have more than one custom field and if you do not check for the script then you will have multiple script tags.

3) Now let’s for a moment assume that EE 2.0 will include jQuery 1.2.3, and the next release EE 2.1 includes jQuery 1.3 (need to stay up to date right), we are back to problem #1.

Yep… The other issue here is that older modules might rely on older versions of jQuery which might not be available in more recent versions of EE.

I guess the only safe way is to write your js without libraries therefore there will be no conflicting methods.

So is there a solution to multiple developers wanting to use JS that doesn’t conflict with older / different libraries?

Is there any kind of checking we could add to the script? Maybe a check to see if a more recent version has already been registered?

//if library is registered
// check the versions
// if there is a version thats higher
// do something
// if its lower
// maybe unregister? (seems like a bad thing to do)
// maybe warn the user on install of this addon?

With EE 2.0 around the corner maybe this is just a storm in a tea cup. It is interesting to discuss these issues and get some real world opinions.

Cheers Leevi

For anyone interested heres how WP does it: http://svn.automattic.com/wordpress/trunk/wp-includes/script-loader.php. Seems bloated like the rest of Wordpress but they obviously face some of the same issues we potentially do.

Leevi,

I’m going into testing on this with some of my modules. It’s ridiculous, but we have trouble with compatibility even in our own library of software.

This is temporary of course as I hope to never have to worry about loading jQuery again once 2.0 comes out.

I plan to use this approach, a modification to yours that I just want to experiment with:

$SESS->cache[‘scripts’][‘js’][‘jquery’][‘123’]

If this doesn’t behave the way I want, I’ll revert back to your approach.

mk

Leevi, I’m going into testing on this with some of my modules. It’s ridiculous, but we have trouble with compatibility even in our own library of software. This is temporary of course as I hope to never have to worry about loading jQuery again once 2.0 comes out. I plan to use this approach, a modification to yours that I just want to experiment with: $SESS->cache[‘scripts’][‘js’][‘jquery’][‘123’] If this doesn’t behave the way I want, I’ll revert back to your approach. mk

Bring On EE 2.0 😊

So with your approach you would just check if the variable is set to TRUE… Sounds much easier 😊

I was also thinking that there may be some issues with other libraries so I am thinking about moving all my jquery to non-conflict mode….

Leevi,

I have this running across about 4 add-ons running in the Edit CP at the same time

$SESS->cache[’scripts’][’js’][’jquery’][’123’]

It’s working well. I like the flexibility and the breakout that it provides. You ok with it?

mk

The only issue I have is that your solution doesn’t cover the issue of having the js file stored in different places … but then again I guess it doesn’t matter if the script is already inserted by another extension.

So an example would be:

if(isset($SESS->cache[’scripts’][’js’][’jquery’][’123’]) === FALSE)
{
    // output script to CP
    // set sesson
    SESS->cache[’scripts’][’js’][’jquery’][’123’] = TRUE;
}

Exactly. We don’t really care about the value of the array key, we only care that the array key exists. So setting boolean gobbles the least memory.

mk

Ok so its all good so far… I guess we will need to document this fairly well… I would suck if another developer set

SESS->cache[’scripts’][’js’][’jquery’][’123’]

and didn’t add the script to the cp source code.