I am working on a new JavaScript architecture for a web app iteration. The previous iteration had lots of inline code, scattered includes, no directory structure for .js files and everything was in the global namespace. I am aiming to: keep the script includes in the footer, keep everything in an application namespace/object, add organization to the .js files and minify all the application specific files in to one bundle.js
I am trying to take a modular approach based on Nicholas Zakas: “Scalable JavaScript Application Architecture” http://www.yuiblog.com/blog/2009/09/17/video-bayjax-sept-09/
the site is currently structred like so
/app
/models
/views
/home
/auth
/meta
about.tpl
contact.tpl
privacy.tpl
/controllers
home.php
auth.php
meta.php
/public
/js
core.js
/modules
module files here
/jquery
jqueryplugins here
/controllers
home.js
auth.js
meta.js
the controllers have methods which correspond to our url routing and view rendering. For example http://localhost/meta/contact
would call the "contact" action on the "meta" controller and render the meta/contact template.
I am planning the js architecture around a single initialization call to the apps global object passing it the controller and method as arguments i.e.
localwebapp.init(controller, method);
At this point in the design I am struggling on inheritance and module implementation. Some modules will be global and be used throughout all the site, some modules will be used through out specific controllers, and some modules will be on controller actions only. Modules are independent and will not communicate with each other they will need to be assigned to a "sandbox" which they will check with for event triggers
I'm thinking I will need sandbox and module classes. The controller scripts will basically be a few lines of modules being assigned to the sandbox and initialized.
Let me know if I am reinventing a wheel here. Any direction is much appreciated. I have looked in to javascript MVC frame works like JavaScriptMVC but it looks like it is not what I need
We use JavaScript MVC as well. You can use both in an application.
In our case, our application is more frontend driven and the backend side (ZF with MVC) is a REST API and JavaScript MVC makes it easy to do so. The feature set is still in the PHP part, and not client-side, we just utilize a lot of parts of JavaScript MVC to make it look snappier, etc..
In the end, I see no reason why it couldn't be the other way around though.
I think the misconception about the view part in MVC is that it's something to see in the browser. The view can be XML or JSON as well. I'm sure you know that, but I wanted to emphasize this part since it is what throws most people off.
If you generally ask about JavaScript MVC -- I don't know if it's the best MVC framework (client-side-wise), but it forces you to define models, controllers and it comes with a testing framework to make sure things go according to plan.
Let me know if this helps!