BackboneJS site structure - javascript

Ok I am trying to get my head round this whole backboneJS thing. I understand you have to separate your site into modules and break each module down into Models, Collections and Views like described in this example.
My JS file structure currently looks like this:
-js
-application.js
-lib
-jquery.min.js
-backbone.min.js
-underscore.min.js
-modules
-newsfeed.js //activity feed
-file.js // page to upload files to
-members.js // page that show other members of group
//-general-site-logic.js??
I have two questions:
Should all application logic be controlled from BackboneJS? If not then where should this separate logic reside in my application structure? Surely backbone can't control all of your client-side activity. What about activity that doesn't involve any collections?
Should I be using RequireJS to manage modules when using BackboneJS or not? I have found this example but it seems to complicate the already confusing concepts of Backbone even further.
I am about to embark on a very javascript heavy app and really want to get this right before my code begins to mushroom!

The great thing about Backbone is that it is just a collection of useful pieces that you can put together however you want. You can organize it however you want.
Surely backbone can't control all of your client-side activity.
Why not? I have a rather large client-side app where all of the code (aside from jQuery plug-ins and such) is written using Backbone constructs (Views, Models, Collections, Routers).
In our case, we are using Rails, so we don't need to worry about requiring other JS files. We break the project up into many js (coffee) files and the "asset pipeline" merges it all into one js file for us. (we do need to tell the asset pipeline some ordering rules, however... models before collections, collections before views, etc)
When we do this, we have the following setup:
-assets
-javascripts
-backbone
-collections
-helpers
-models
-routers
-templates
-views
-bootstrapper.js
Of course, that is how WE do it. For larger projects, I always know where to find my components and we create subfolders within for our different sub-views. For instance:
-views
-people
-people_list.js
-people_item.js
-orders
-order_list.js
-order_item.js
-order_form.js
On smaller projects, however, you can put everything in one JS file and it wouldn't be a problem. Most toy examples are laid out this way.
An intermediate layout might be something where you just separate your models from your views like this:
-models.js // models and collections
-routers.js
-views.js
I guess what you should get from this is: "Organize however you'd like". Do what makes sense for the project size and your team's understanding of organization.
Backbone provides structure. It isn't opinionated, however, to how that structure is designed.

If it helps I have a bootstrap, project starter integrating backbone.js, coffeescript, sinatra, jasmine and skeleton.
It'll get you started with project structure and save you time integrating the tech stack. Also uses skeleton css for responsive design.

Related

How to adopt MVC in a web application?

I'm currently working on a web application which uses HTML, CSS, Javascript, Bootstrap and JQuery. I will like to use Model–view–controller (MVC) as my software design pattern. So far I have 7 HTML pages and each page has a corresponding controller in Javascript. And these HTML pages shared some "global" CSS & Javascript (Bootstrap & JQuery). I'm unsure how to organise my files to demonstrate MVC clearly. Am I right to say:
MODEL (some files which manippulate data?)
VIEW (all my HTML & CSS files)
CONTROLLER (all my Javascript files)
Does this means I have 3 folders (MODEL, VIEW, CONTROLLER) and I simply place all my files accordingly?
Sorry is my 1st time adopting software design pattern, sorry for any confusion caused. I will like to know more about how to implement MVC effectively as I feel is important.
Well it depends on the approach. But to give you a clue of best practice you don't necessarily need to have a controller for each page, in fact it will be more like a view for each page, a model for each data entity and a controller for performing the actions of data binding, in most of the cases you will be having a similar number of controllers and models. The controller usually will be the one choosing which view to show, parsing the data for such a purpose, and invoking data synchronization actions. Keep in mind : "controllers does stuff".
You can read about MVP pattern (Model-View-Presenter) which similar with MVC and used in frontend.
Also you can see examples of todolist mvc (vanilla javascript, jquery). Here is cool code organization.
What about folder structure, You can apply different approaches, but for several pages it's good idea to create folders like models, views, controllers, helpers and so on.
p.s. Together with the models usually used collections (list of models). You can see how organized Backbone (library) structure.

Styling and Connecting the Backbone to a Ruby Server

So I've been doing a lot of learning on Backbone, Sass, RoR, Bootstrap, etc. and I am extremely frustrated that no sources I've found (including in Tuts+ and Code School) mention any way of putting it all together...I have no clue how to style a web page if all of the contents I want in the page are being built through backbone...so if I want to click on the "About" page on a website, have all that page's Backbone contents styled correctly when appended to the DOM.
Secondly, I'm not sure how I should be creating these web pages for a website; should I be creating the whole page in Backbone and then keep that on the server until someone clicks on, for example, that "About" page and then have the whole page loaded into the view? Or am I totally misunderstanding one of the ways you can use Backbone? Along with this then, how am I supposed to communicate Backbone to a Ruby Server? just using Ajax?
I'm looking for sources and anyone who can help me understand this stuff in clear terms!
Thanks so much,
-Stu.
Presuming that you want to build a single page app it is important to understand each one responsibilities:
Rails
Create a full stack application that runs on server
Create a consumable API
Manage assets pipeline
...
Backbone
To manage your frontend javascript application
Decouple data from the views using Models
Connect an API over a RESTful JSON interface
...
Keep in mind this is a oversimplification of both...
Rails will handle the backend, retrieving an API to be consumed by Backbone. The Rails assets pipeline will deliver all files that Backbone needs, including the css that will style you app.
It might be somehow confusing since you will hear concepts that eventually will clash between them, like in both ends will have Models, Views and Router, but they will live live independently from each other, one will work on the server-side (Rails) and the other on the client-side (Backbone).
To give an example:
Rails would render:
domain
|-index.html
|-js/*.js
|-css/*.css
`-api/*.json
Backbone would use the DOM (index.html) and the js scripts to execute logic, append the views into the DOM and Read/Write data using ajax through the API.
Another confusing thing would be views, since Rails will generate those for you, and backbone will also have their own views, so the usual setup:
In the client-side, Backbone will be have at least the following parts:
Router — it will orchestrate your app, binding an event a route, let's say /#about page and create a view and pass the respective model:
Model — it will request data from the API and dispatch an event when done
View — it will use a template to render the model data
In this case Rails would manage the page assets and provide the API, Backbone would have it own router, models, views and templates to render the page on the client-side.
This also means that the way you combine both it could be only answered regarding the project specificities, and there a lot of ways to use both.
That said, IMHO it's really important to first understand how a full Backbone app works,
then use something like backbone-rails gem, to see how both can be managed in a consistente way.
I know what you mean--there's a lot of random tutorials out there for Backbone but not a lot that put it all together. To a certain extent that's just how it is, unfortunately, but I'd say once you're past learning the basics from Code School and others, the hands down best resource for how to actually build complicated apps is:
BackboneRails: http://www.backbonerails.com/
It covers the stack you're talking about mostly. The first few screencasts are free and then subsequent ones are paid but well worth it. Building on the skills I've learned from BackboneRails and I've built several fairly complicated apps that turned out great. Good luck!

Should I use a resource loader for a SPA, or front-load everything?

I've been getting into Backbone.js lately and I'm enjoying it so far. All the examples tend to be simple to-do lists, so it's been a little difficult extrapolating code organization and file structure for a larger/more robust single page application.
I've come to a crossroad:
Should I use something like Yepnope.js to load models and views as I need them or,
Combine and minify into fewer files and front-load it all.
Some combination of both?
Any advice would be appreciated!
It depends of the size of your app. If you have a bunch of different views its definitely worth to start with a loader, where you can start the app with minimal feature set and load other views when needed. I can't tell anything about yepnope, but it seems the focus is more about polyfills then to structure your app with modules. We use requirejs for our app, and it works really well. You have to write a bunch of boilerplate code for the AMD modules but its really worth it.

extjs application architecture

I am developing a extjs application, and I am just a starter.
It's quite different develop mode for me, and I feel puzzled.
My first question is about client-end architecture, I'm developing a little app now, so I wrote all js codes in only one html file, what if I need to develop a huge app?
like this: [Article Manage(leaf in tree)] -> [CURD List(Data Grid)] -> [Edit Article(Dialog Box)]
There will be lot of leaf in my tree, so there are many XXX Manage.
What should I manage my client-end js files(file structure or something else), and how to load these files dynamically? Is there any exists demo?
um.. maybe what I really want to ask is:
How to put my code for every module into different js files and 'include' the dynamically?
I've got the answer, just use loader property of a container component, this method fit me well. Thanks to all of you.
There are no patterns set in stone, but here's one way to Write a Big Application in Ext 3.x.
Another good resource for ideas, generic to JavaScript, is Nicholas Zakas's video on Scalable JavaScript Application Architecture on YUI Theater.
In my mind the big things to do are:
Write standalone components (think: UI container, data structure, etc) with no dependencies to other components on the page.
When you want to two components to interact, have their parent container wire them together.
Have some kind of logical directory structure for development (doesn't matter what exactly), splitting out each of your "components" into its own file -- even if you plan on combining them into a single file for deployment.
Not sure if I correctly understood your question, but I'll try to answer. For bigger applications use MVC pattern which allows you to split your application to components such as Stores, Controllers, Views etc. Then you can easily send data from server in JSON for example (using server-side technologies - php, java,...) and read it by Stores proxy. If you look into Samples & Demos they're also loading some bigger structures using php script which returns JSON.

How to structure Javascript architecture to complement a PHP MVC web app?

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!

Categories