We Keep Coding

Symfony including assets (stylesheets/js) based on the controller

I am trying to find a good way to make my js and css modulo. The thought came to me that when a particular controller is run, it would automatically find a corresponding css/js file and add it. E.g. if i run the TodoController, then a TodoController.css file will be automatically loaded.
Has anyone done something like this?
If its not really the way to go, then how would one load the assets needed per controller?

The right approach would be loading assets based on the views, resp. logical areas of your project and not on the controllers.
The Twig templating system has a powerful inheritance ability, so you can define base templates for specific areas of your project (with specific assets) and then extend these with templates for particular views (a.k.a. pages).
You can learn more on this here: http://twig.sensiolabs.org/doc/2.x/templates.html#template-inheritance

NODE and CMS with angularjs: how do they cooperate

I'm thinking about making something with the MEAN stack. I need a way to edit the content of the site, like e.g. Wordpress offers (basically a CMS).
The confusing bit is how the CMS and Angular would work together. I've looked at a CMS named Keystone, and there you have to set up some routing etc. in Node. Won't this crash with the routing you set up in Angluar?
In other CMSs I've used, the creation of the views happens on the server side. In Angular, as far as I understand, you crate a HTML template, which you can populate with data in an angular controller. This also seems like something that could crash between CMSs and Angular. Is this the case?
Is there any other quirks or similar about Angular and content managment systems I should know about, or is it usually not much problems integrating the two?

meanjs.org has a pretty good approach to this. Install meanjs. It comes with a sigin/signup and even allows you to create articles from the vanilla install.
Put simply, when you are creating a web app with the MEAN stack, think of AngularJS as "THE" app, and node.js as the api.
If you approach building your web app as a javascript application (AngularJS), that happens to get its data from an server api (node.js), then you will begin to understand how to properly use the MEAN stack.
First: Angular will have the routes defined in the $routeProvider. Build the routing urls in AngularJS first. They are "THE" routes for your web app. A good way to look at it is to build the AngularJS portion with the ability to change your api server, even to another language (PHP, python, go, etc) if necessary.
Second: Build your AngularJS to communicate to the api with $resource. Essentially a $resource is an easy way to call out to an api using restful routing. This "restful routing" is now the routing that needs to be "mimicked/copied" into the routing for the node.js routes.
Often the AngularJS routes (the url) will match the $resource routing that matches the node.js routing.
Again, take a look at meanjs.org and you will have a better understanding on how to properly organize what "seems like" (and actually are) two separate apps.

Basically, you need three sets of routes (or two if you are doing it on the cheap).
Start out with a set of routes on the server that return regular webpages. Forget about JavaScript. Do not involve Angular at this stage.
Second, add another set of routes on the server which return data in a rawer form (such as JSON). This would typically be a RESTful API.
Third, add Angular to the client. When the view needs to be updated, update the URL in the browser and use Ajax to hit the RESTful API to get the data needed to populate it. (You want the URL you set the address bar to to match the URL of the page from the first set of routes that you are duplicating with JS and the data from the RESTful route).
If you are doing it on the cheap, like Gawker did, then you would skip the first set of routes and go direct to the JS+REST approach.

I think you need CMS on MEAN stack development environment.
there are some cms on mean stack you can try.
PancilBlue
Calipso
try this.

I was trying something similar, I found this link very useful AngularJsCMS It has told about free respond cms which is based on angularjs and have the ability to create pages like wordpress and manage contents.

We have been working on a project using angular and keystonejs. Simply serve the default template layout found in keystone and inject the data-ng-view tag within the body tag. Serve this template for all requests to '/'.
Then write your angular app normally to consume endpoints. These endpoints can be done in keystone using the api middleware. In the routes/index.js file add a key/value pair in the routes object with the name of your custom endpoint then import the folder containing your endpoint function definitions.
var routes = {
views: importRoutes('./views'),
api: importRoutes('./api')
};
exports = module.exports = function(app) {
app.get('/api/posts', keystone.middleware.api, routes.api.post.index);}

I recently migrated my blog over to MEANie - a lightweight custom MEAN Stack CMS that I developed.
I made it open source for anyone to use and posted details and setup instructions on my blog at http://jasonwatmore.com/meanie.

Create url in sails js node framework

In many web frameworks (I am familiar with the Yii php framework) you are able to use some application component to create urls you can then use in various places in your application. You can usually give it a controller/action or some other combination of parameters and it will return a url eg. http://mydomain.com/index.php/<controllername>/<actionname>
The main thing you gain is that the application takes care of building urls and you aren't left ever hard coding url paths around the place.
My question is, does anyone know if the node sails js framework has such a thing or, if not, perhaps someone has written a module on npm that achieves this nicely?

Sails uses blueprints that do things similar to what you want. They provide a few different blueprints, for common things like CRUD or REST but they also have "Action Blueprints"
If you have a controller foo (FooController.js) that has action bar, it will be automatically accessible via /foo/bar when action blueprints are enabled (they are enabled by default)

BackboneJS site structure

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.

Best Way to Organize an ExtJS Project

I've just started developing an ExtJS application that I plan to support with a very lightweight JSON PHP service. Other than that, it will be standalone. My question is, what is the best way to organize the files and classes that will inevitably come into existence? Anyone have any experience with large ExtJS projects (several thousand lines).
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­

I would start here http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/
This site gives a good introductory overview of how to structure your application.
We are currently using these ideas in two of our ASP.NET MVC / ExtJS applications.

While developing your application your file and folder structure shouldn't really matter as you're probably going to want to minimize the release code and stick it in a single JS file when you're done. An automated handler or build script is probably going to be the best bet for this (see http://extjs.com/forum/showthread.php?t=44158).
That said, I've read somewhere on the ExtJS forums that a single file per class is advisable, and I can attest to that from my own experience.

I suggest users are willing to wait for an application to load, so we typically load all of JS during initial app startup. I suggest loading and eval'ing JS files as needed is unnecessary - especially when all JS will be minified before deployment to production.
I suggest namepsaces, one class per file, and a well-defined and well-documented class hierarchy.

When starting new big project, I decided to make it modular. Usually, in big projects not all modules are used by a particular user, so I load them on demand. F.e., if a project would have 50+ modules, the big probability is that user is working only with 10-.
Such architecture lets you to have the initial code relatively small.
Modules are stored on the server and loaded by AJAX call, eval'uating the responseText in AJAX callback. The only issue with this, you must keep track on module dependencies, which could be stored inside modules as well. I have a class called Module, and I check every new module instance for existance within the task. If it doesn't yet exist, I load it from the server.