views:

527

answers:

4

I'm building a website where many of the pages are very interactive without having any communication with the web server. Basically, a page represents a kind of DHTML interface, where users can click on various divs to move them around and perform other actions. In the end, the user is able to save the "state" of all divs on the screen and only then the HTTP request is sent to the server.

I'm trying to use MVC approach (via CodeIgniter) and these actions are mostly handled by JQuery and a few custom JavaScript functions I wrote. I have a lot of JavaScript code that covers the logic. Currently, all the code is in the View of CodeIgniter's MVC, but I somehow feel that is wrong. I'm thinking I should move some of the code to some kind of controller, but a JavaScript one instead of PHP controller provided by CI.

Should I create some kind of a parallel MVC in JavaScript?

A: 

You could. Look into Asset Helper. It allows you to set up whatever kind of structure you want, without interfering with CodeIgniter's structure at all. It sets up a sort of asset area, and you can set up your own modules however you want. You might think of a different kind of separation for them, though, as Javascript is probably going to deal mainly with View, especially if you aren't using an AJAX. So, consider packaging your javascript (a la Java) into separate folders with logical grouping. Then, using the asset helper, it's just a simple line of PHP to tell your program to use whatever you want.

Peter
I examined this, but it can only be used to mix in the handling of scripts in the controller. It doesn't really separate the view/controller logic in the JavaScript itself.
Milan Babuškov
+3  A: 

As an aside, another thing you have to look out for with implementing business logic code in JavaScript is that the code you're running runs outside the your application's trust boundary -- that is, because it runs on each client, it is technically possible for a client to send you bad data. That can be a big problem, especially if you have authorization logic in the front end.

Not knowing what your code is, I will say that you want to take the code which requires a high level of trust out of JS entirely. Save JS for UI sugar. If you do that, it's entirely acceptable to have lots of JS code in your "view" -- as long as it pertains just to manipulating the client-side presentation.

But yes, on the other hand, I do see how you could view this effort as a model-view-controller(Client)-controller(Server) pattern. But I think that's OK...

Dave Markle
+1 for the client side risk. But in the last line you have said that model is on the client side, its again a risk right?
Pradeep
Application is used to model user interface, so I'm not afraid of the "bad" data. Consider something like <a href="http://www.yaml.de/en/">yaml</a> with ability to save settings to the database or something like that.
Milan Babuškov
I didn't mean to insinuate that the model belonged on the client by my little "m-v-c-c" description there. Sorry.
Dave Markle
+1  A: 

If you end up having lot's of Javascript code and most of the functionality running client side, server side cannot help much. You need to have your JQuery and other JavaScript code organized well. Not sure if there are any MVC frameworks existing specifically for JavaScript. Did one of my own years ago when had to work with the project with huge loads of JavaScript. However you don't necessarily need to do full blown MVC, just having simple model in place and handlers (controllers) for the logic in place will help you a lot. But if you code relies on JavaScript it's a biiiig mistake if you don't really thing how you construct your JavaScript software.

tomtom
Thanks. I decided to simply keep all the JS code in .js file and include those directly in HTML view. I keep the logic in .js code and put all representation in CSS id's so I do get some Controller/View separation. And there is a final Ajax code that behaves like storing data to the Model finally.
Milan Babuškov
+1  A: 

JavaScriptMVC is an excellent choice for organizing and developing a large scale JS application.

The architecture design is very pragmatic. There are 4 things you will ever do with JavaScript:

  1. Respond to an event
  2. Request Data / Manipulate Services (Ajax)
  3. Add domain specific information to the ajax response.
  4. Update the DOM

JMVC splits these into the Model, View, Controller pattern.

First, and probably the most important advantage, is the Controller. Controllers use event delegation, so instead of attaching events, you simply create rules for your page. They also use the name of the Controller to limit the scope of what the controller works on. This makes your code deterministic, meaning if you see an event happen in a '#todos' element you know there has to be a todos controller.

$.Controller.extend('TodosController',{
   'click' : function(el, ev){ ... },
   '.delete mouseover': function(el, ev){ ...}
   '.drag draginit' : function(el, ev, drag){ ...}
})

Next comes the model. JMVC provides a powerful Class and basic model that lets you quickly organize Ajax functionality (#2) and wrap the data with domain specific functionality (#3). When complete, you can use models from your controller like:

Todo.findAll({after: new Date()}, myCallbackFunction);

Finally, once your todos come back, you have to display them (#4). This is where you use JMVC's view.

'.show click' : function(el, ev){ 
   Todo.findAll({after: new Date()}, this.callback('list'));
},
list : function(todos){
   $('#todos').html( this.view(todos));
}

In 'views/todos/list.ejs'

<% for(var i =0; i < this.length; i++){ %>
   <label><%= this[i].description %></label>
<%}%>

JMVC provides a lot more than architecture. It helps you in ever part of the development cycle with:

  • Code generators
  • Integrated Browser, Selenium, and Rhino Testing
  • Documentation
  • Script compression
  • Error reporting
Justin Meyer