Calling all developers! Registering javascripts... lets reuse the ones already there
Development and Programming
Hey guys,
I had a thought tonight about using javascript in custom modules and extensions in the ExpressionEngine admin. The more extensions and modules that are released the more chance that someone else is already using the same library script you are.
The Issue
Extension 1 includes the following script: (square brackets are used in this example)
[script type="text/javascript" charset="utf-8" src="http://site.dev/scripts/jquery/jquery-1.2.3.pack.js"][/script]Then another developer who doesn’t know your script has been installed also wants to use jquery so they include:
[script type="text/javascript" charset="utf-8" src="http://site.dev/scripts/jquery/jquery-1.2.3.pack.js"][/script]That’s an extra call to the server to load a file that already has been included not to mention the extra processing power needed to run the JS lib a second time.
So I thought of a quick solution and posted it over to ExpressionEngineer to see what he thought.
The idea is that we all use $SESS->cache to track which javascripts have been included. It would work something a little like this…
Inside your extension / module class you would include the following method
The Method
function _register_script($file_name, $library, $folder_path = 'scripts')
{
// get the globals
global $SESS, $PREFS;
// if the script has not been included by another extension / module
if(isset($SESS->cache['registered_scripts'][$file_name]) === FALSE)
{
// add it to the session so we know for next time
$SESS->cache['registered_scripts'][$folder_path][$library][$file_name] = $file_name;
// return the script tag to use in the output
return '[script type="text/javascript" charset="utf-8" src="' . $PREFS->core_ini['site_url'] . $folder_path . "/" . $library . "/" . $file_name . '"][/script]';
}
return '';
}and when you want to include a script do that by calling the method
The Method Call
$output = $this->_register_script('jquery-1.2.3.pack.js', 'jquery');By default this would mean that all scripts are stored in the scripts folder in the site root. Of course this could be changed by passing a third parameter.
I think this is a pretty sound solution but I’m throwing it out there to see what you guys think
Cheers Leevi
I’m following you closely on this one, I love the initiative. JS files all over the CP has been a cause for concern more than once, now if all other devs would just chime in too, this would be golden!
Thanks Leevi.
edit: spelling
Having recently come to EE from the drupal camp, I know that one of the things I liked about drupal’s core was its inclusion of jQuery. Anyone who developed a module for the drupal community could safely assume that jQuery was installed and could leverage it’s power. I’m sure there are benefits to not being tied to a particular javascript library, but standardization has some nice benefits.
I’m not sure how details of how MIT or GPL licensing works. So I don’t even know if this is even an option.
You can use Prototype and jquery together on 1 page…soo why not include then both on the back-end 😊
Since jQuery is a svelte 15kb minified/Gzipped library, why not? But let’s not leave out mootools, extjs, yui, mochikit etc. 😊
The solution presented allows you to use any library you like jquery, prototype, mootools, ext etc.
The issue is that there is a chance the same library will be included more than once possibly in different file paths.
What I would like to see in a nutshell is:
- One place for scripts
- A process of registering those scripts so they are not requested more than once
The inclusion of jQuery would be great (I am a jQuery user) but unless its used in the core then it would be hard to maintain. It also opens up a can of worms regarding which libraries to include.
Leevi,
You’re approach would be the way to go on this. I’d say get Paul’s thoughts and try to get the method into the EE developer docs so we can all adopt.
mk
Leevi, You’re approach would be the way to go on this. I’d say get Paul’s thoughts and try to get the method into the EE developer docs so we can all adopt. mk
Yeah that’s not a bad idea. I don’t want to push this as the required way to work but I think it can save us all some time adding scripts and ultimately speed up the admin for the users.
As a one of the leading EE independent developers I appreciate your input 😊
Developers are getting a good deal of attention in 2.0. Beyond that I cannot disclose any details of what’s in store for you, not even a yay or nay. Some things we will be free to discuss at SXSW, and some things will have to wait for the developer preview/beta. Continued feedback from our experienced third party developers is always appreciated, though, so please continue.
Developers are getting a good deal of attention in 2.0. Beyond that I cannot disclose any details of what’s in store for you, not even a yay or nay. Some things we will be free to discuss at SXSW, and some things will have to wait for the developer preview/beta. Continued feedback from our experienced third party developers is always appreciated, though, so please continue.
Hey Derek,
Thanks for your feedback.
This idea relates to development generally for the current (and possibly future) builds of EE. Its not necessarily a feature request directed to the dev team for 2.0 but more of an overall concept we could start using now.
Do you see any issues with independent developers implementing something like this right now?
Cheers Leevi
The danger (perhaps too strong a word) of us officially endorsing and documenting something like this at this time is that that creates a standard. Converting your add-ons for 2.0 will already require some modifications, and with that time approaching ever closer, it seems that adopting new development standards at this time would be premature and possibly create more work for you down the road.
But no, I don’t see any problem with developers who are in agreement with one another to collaborate and implement this in your add-ons, but to really stand behind it properly for 1.x, we’d need to define some guidelines and possibly some additional directory structures to support the effort cleanly, and that’s not where our efforts are focused at present.
Fair call 😊
Oh, and I still don’t see you on the guest list, Leevi. How many beers will it take to get you to cross the pond?
Oh, and I still don’t see you on the guest list, Leevi. How many beers will it take to get you to cross the pond?
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 😉.
I’m saving for next years EE 3.0 release at SXSW 😊
Wait a tic, you’re across the other pond (Pacific) right now, aren’t you? I’ve been looking for an excuse to host a developer event in Oceania anyway.
Wait a tic, you’re across the other pond (Pacific) right now, aren’t you? I’ve been looking for an excuse to host a developer event in Oceania anyway.
Well Newcastle is the place…
1 1/2 hrs away from Sydney, easy flights from Brisbane & Melbourne nice beachs, good pubs, good conference facilities at the University.
Something to consider 😊