JQuery is cool, it is a well known JavaScript framework that allows you to create DHTML nicely using selector and method goodies. The problem with jQuery, seems that some developers are messing the code a little bit, so many of them are using inline JavaScript to handle some events. This is a very bad practice, so you should centralise all events in JavaScript files, rather than placing the inline <script/> tag. So, the first step is to create a separate JavaScript files to leave a clean and plain HTML files on the server. Then you can handle a page specific configuration and jQuery event handlers using a very simple and object oriented technique.
The first step should be the creation of an application object in JavaScript which will hold specific functionality handlers.
var _my_app = false; var __handle_exception = function(e) { if (console && console.dir) { if (typeof(e) == "string") { console.log(e); } if (typeof(e) == "object") { console.dir(e); } } else { alert(e.message); } }; var MyApp = function (event) { try { /* application constructor */ this.install_preload_json(event); this.install_common_setup(event); this.install_date_pickers(event); } catch (e) { __handle_exception(e); } }; MyApp.prototype.install_preload_json = function (event) { try { /* preloaded JSON data */ } catch (e) { __handle_exception(e); } }; MyApp.prototype.install_common_setup = function (event) { try { /* common handlers */ } catch (e) { __handle_exception(e); } }; MyApp.prototype.install_date_pickers = function (event) { try { /* date pickers */ } catch (e) { __handle_exception(e); } }; $(document).ready(function (main_event) { _my_app = false; _my_app = MyApp(main_event); });
We have created our JavaScript application using jQuery and object oriented approach, with individual handlers for each application component. Instead of loading all of them on the constructor, we replace the constructor with a configurable field allowing only a limited number of required settings per page using a very simple routine that will handle the required handlers for each page. Then MyApp constructor will replace all calls to this.install_... methods by the page-required methods to complete a functionality.
var MyApp = function (event) { try { /* application constructor */ this.run_app_installer(event); } catch (e) { __handle_exception(e); } }; MyApp.prototype.run_app_installer = function (event) { $(document).ready(function (m_evx) { try { var actions = $('#page-actions').val(); if (!actions || actions == undefined || actions == '') { return false; } actparts = actions.split(","); for (var i = 0; i < actparts.length; i++) { if (typeof(_my_app[actparts[i]]) == "function") { (_my_app[actparts[i]])(m_evx); } } } catch (e) { __handle_exception(e); } }); };
The code above will look for an input element holding a series of events that would be handled on the application startup. If we have an input element with ID page-actions and it holds preload_json, common_setup, date_pickers as comma delimited value, the application should run only those handlers, instead of running all application handlers at once. So, if we add the following HTML in the application page, it would work fine.
<input type="hidden" name="application_handlers" value="install_preload_json,install_common_setup,install_date_pickers" id="page-actions" />
This allows a restricted execution only to those handlers that we want to install, avoiding excessive execution and helping in the page performance. Among other stuff like encapsulating the JavaScript in a separate file which can be compressed using the yui-compressor, as the CSS can be compressed using the csstidy command. So, the page should not have inline JavaScript and must have separate JavaScript files, compressed and using an object oriented approach rather than using plain functions to work. I think that this approach is very simple and helpful, I hope that you will find it useful too. If I code at this level of order, just imagine what do I think of those projects that you are presenting to me.