Hey! I'm trying out Backbone.js and have followed the annotated source of the TODO's app.
I fail (don't know how this should be done) when trying to implement projects, which has tasks as "children". So that i can change project and view different lists of tasks.
How should i do this? Some tips for beginner tutorials would also be great :)
The backbone docs mention a pattern for doing something like this:
http://documentcloud.github.com/backbone/#FAQ-nested
So, I would create a new model called a project that has a property called 'tasks' which is an instance of a TodoList collection.
I can't speak to storing the data, as I've never looked at the localStorage used in the TODO app.
Related
I am trying to develop a Backbone Marionette application and I need to know how to do CRUD (Create, Read, Update and Destroy) actions in the best way. I cannot find any resources explaining this (only for Backbone).
Any examples out there?
Marionette is a library on top of Backbone think about it like jQueryUI for jQuery and aims to help you to scale your aplication allowing you to modularize it, among other things like saving you from writing a lot of repetitive code.
So there wont a lot of CRUD exameples, the exampels will try to prove the benefits of marionette.
however I think this two tutorials will help you.
http://davidsulc.com/blog/2012/04/15/a-simple-backbone-marionette-tutorial/
http://davidsulc.com/blog/2012/04/22/a-simple-backbone-marionette-tutorial-part-2/
http://davidsulc.com/blog/2012/05/06/tutorial-a-full-backbone-marionette-application-part-1/
http://davidsulc.com/blog/2012/05/13/tutorial-a-full-backbone-marionette-application-part-2/
You can find a more advanced CRUD application example here:
https://github.com/nuragic/marionette-bootstrap
It illustrates (among other things) how to structure your application with "modules".
I'm new to Backbone.js. I have gone through the documentation. My question is
where does the controller concept come into picture? In other words, what is a controller in Backbone.js?
I heard that the router is the controller. If so, why it is considered as a controller? Can we develop simple basic apps without the Router also? In that case what will be the controller?
To clear things a little bit here. A Router is not a Controller, It's a way to define a client-side route map (similar to Rails's routes.rb). This helps routing client-side pages to certain actions/handlers. And that's different from a controller's job which is to provide a bit of orchestration between Models and Views. And there is actually more than one way to do this using Backbone. Quoting from Backbone's documentation:
References between Models and Views can be handled several ways. Some
people like to have direct pointers, where views correspond 1:1 with
models (model.view and view.model). Others prefer to have intermediate
"controller" objects that orchestrate the creation and organization of
views into a hierarchy. Others still prefer the evented approach, and
always fire events instead of calling methods directly. All of these
styles work well.
This brings three different approaches to accomplish this. The first one is pretty straightforward which is to have the model object included as a property to the view.
The second one proposes including a third component that performs this role of orchestration. I believe this can be helpful in quite large and complex applications. For this I encourage you to look at Chaplin, a sample application architecture using Backbone.js. The guys have done a great job in separating things out and also introduced the concept of a Controller into the architecture.
The last approach is suggesting using events to mark for actions and mediator to handle these actions. For this I encourage you to look into the mediator and Publish/Subscribe JavaScript patterns.
Check out Addy Osmani`s article on MV* on the client:
http://addyosmani.com/blog/understanding-mvc-and-mvp-for-javascript-and-backbone-developers/
From the article:
In Backbone, one shares the responsibility of a controller with both the Backbone.View and Backbone.Router.
and
In this respect, contrary to what might be mentioned in the official documentation or in blog posts, Backbone is neither a truly MVC/MVP nor MVVM framework.
It's more similar to how for example iOS Cocoa Touch framework works, you shouldn't think about it like a backend MVC, backbone team itself even never mentions MVC on their website to avoid confusion people often have when coming from backend MVCs. The View in backbone is what's called in iOS a ViewController/AppController and usually your main AppController will be a View which sets the main wrapper for your application which usually you would also use as a global pub/sub system and controller for your main app logics.
Router is exactly what it say - it converts routes into set of params and passes them to the app controller to figure out what to do with them, what subview to load etc. (or if application is less sophisticated it can load/change the views straight from the router level) - It used to be called controller but it was renamed in (0.5 I believe?) to clear this confusion.
At least this is our approach - if you checked multiple tutorials in the wild you've probably seen that when it comes to Backbone there are as many approaches to this as many developers there are. And that's what is beautiful about Backbone! :)
Usually I make my own controllers, and let the router do it's thing (catching routes, and pointing towards a controller action). These controllers are home made, just javascript objects with methods on them. They take the request from the router, collect the right data (collections, models...) and take the necessary view, combine them and pass the data into the view.
from there on it's backbone again.
however recently I came arcoss a 3rd party backbone plugin called backboneMVC. Have read it's documention, but have yet to try it out myself.
It aims to take over your router and make routes based on your controllers and actions you define with it.
Take a look at that library however I cannot promise anything because I have yet to build something with it myself.
I would like to create for my Yii application, a site where I can describe each model, view and controller used. However, doing this for each and everyone of my classes would be an extremely long task which I believe might already be solved out there.
Is there a way to automatically create an site with each model/view/controller and its methods, so then I can add a description to it?
Have you tried phpDocumentor http://www.phpdoc.org/? It's crawls your PHP files' comments and generates a simple website for them in the spirit of JavaDocs.
Or, better still, there is a custom extension you can use to build docs like those on the Yii site call Yii Docs Generator http://www.yiiframework.com/extension/yiidocsgenerator. See the details at http://www.yiiframework.com/wiki/186/how-to-generate-yii-like-documentation
I would take a look at T4MVC - it uses a T4 template to generate code for each controller / method. Maybe you could utilize it.
Have you looked into the Gii module of yii. Once you create the tables it can produce models and then CRUD (create, update, delete) pages. Excluding the database there would be no programming required. And then you have the full source in a readable and documented form to manipulate and change to suite your needs.
If you wan't something a bit more advanced or custom you could extend Gii and produce some of your own templates
Larry Ullman has a really nice series on Learning the Yii Framework. In part 3 of the series, he walks you through configuring Yii and enabling Gii, a web-based automated code generation tool for Yii. In part 5, he shows you how to use it to generate the code for your models. The whole series is a really nice introduction to Yii, I recommend it.
I'm a fairly experienced .NET programmer, as well as a MVC programmer with PHP. Now I'm new at MVC3 and trying to build my first work on it, so I'm dealing with a few questions. For starters, how do I extend the Controller Class? Can someone point me to a guide/list of methods I should implement?
Thanks!
You don't have to implement any methods to extend the controller, although obviously it would be rather silly not to. You just inherit from it, and override the methods you wish to alter.
If you don't know what methods to alter, I have to question why you want to extend it?
EDIT:
You may benefit from the two big MVC sample applications, Nerddiner and Music Store. They give you a very good idea of how to make ecommerce sites and the like in MVC. Don't take them as gospel, because they are samples and are intended to be simple. They don't currently make use of best practices like Dependency Injection, or Repository design. Some links to useful tutorials:
Lots of good videos here. The Pluralsight stuff is pretty straight forward
The Music Store tutorial app
NerdDinner tutorial
You don't need to implement anything, just make your class inherit from System.Web.Mvc.Controller. Normally there is no real benefit to doing this, but in some cases it can be helpful make some form of common custom base controller class that all controllers in your project could share.
Beware though, when adding common methods to your controllers. It often makes more sense to add these methods to some lower tier of your application, or as helpers methods on your models or viewmodels.
I'm new to Ruby and Rails and I'm making my first app. Basically I'm parsing HTML and sending it as JSON to the client.
Right now I've two sources for the HTML data but I could have more in the future. Because of this I thought that it'd be a good idea to remove the code responsible to parse the HTML from the controller and put it into a service layer. I came up with this structure:
app
controllers
main_controller.rb
model
project.rb
task.rb
services
source1_service.rb
source2_service.rb
The MainController call both services to get the projects and tasks; each service parse its own HTML.
Is this a good solution? Is there a more RoR way to do this?
put your services in your models directory, there is no rule that all models have to extend from ActiveRecord::Base, but your services are opaquely data models to the rest of your app (if I understand you right). Ideally, let the service code mimic active record so other people that are just using your model code dont have to know its a different than any other model in your rails app.
Unlike in the Java world, 'the service layer classes' concept is not really popular/used in the RoR world. Its a good idea to remove that code form your controllers (you want your controllers to be thin). But i think you can inject them to your models. If you feel its getting too complicated you can break up your extra code into modules and mixin those modules to your models.
Its not the one and only way of doing things though.
However if parsing HTML include some common logic that can be reused, even in another project its a good idea to put it inside the lib/ folder.