Architecting Ember.js Apps
This talk was delivered to the Ember.js NYC Meetup on Wednesday, August 22nd. There is also video is posted at Cloudee.
7 Responses to “Architecting Ember.js Apps”
-
Sylvain MINA chimed in:
I Luke, first of all, you did a very good job here, thank you :)
With my co-workers we were looking for other quite large applications, in order to see if we were doing a good work at designing our app. I think here I’ve got an answer, and it is very usefull as we realize that we are missing some points (for example, too much logic in views, manipulating directly the models).
By the way, I have little questions/comment around this speakerdeck:
* in slide 24, the TodosController definition may confuse beginners, as you affect an empty array to the todos array at declaration time, which could be unsafe if there are multiple instances of this controller.
* in slide 50, you tell that two-way bindings are often uncessary, so do you think the default behavior of binding definition in ember should be one-way ?
* in slide 52 you advice to delegate to separate state managers where possible. I don’t understand exactly what that means. Would it be possible to have an example of this ?
August 24th, 2012 at 7:57 am
-
Séverine Darlot chimed in:
Hello,
Thank you for this presentation.
I have questions about page 9.
What do you want to tell by “MVC is not created equal” ?
When you tell that “controller” has many different meanings, what are the different meanings ? a model proxy ?Could you give me more information ?
Thank you
August 24th, 2012 at 8:28 am
-
lukemelia chimed in:
@Sylvain: Thanks for you kind words and comments! re 24, agreed (although it is uncommon to have multiple instances of the same controller in Ember apps). re two-way bindings, I do personally think that a oneWay default would be better, but not sure how popular that opinion is. re: separate state managers, a simple example is a separate state manager to handle modal dialogs. We also use a separate one to manage a particular sidebar in our UI. The router delegates certain events to those state managers, which handle them and thereby keep the router simpler.
@Severine: Here’s a good page to read to learn about how “controller” is used in software engineering: c2.com/cgi/wiki?WhatsaControllerAnyway
September 13th, 2012 at 4:15 pm
-
Sylvain chimed in:
Hi Luke, thanks for your explanations. Concerning the state manager delegation, you create those separate state managers as children of the router, or simply as member of the application ? Or perhaps you create the state manager when you need them, at event handling time ?
September 20th, 2012 at 1:01 pm
-
Aras chimed in:
Hi, I wanted to watch this presentation — specially since it happens in future — or maybe I am living in the past :). Anyway, I wanted to ask if you could put the video on youtube or viemo becuase the link on cloudee is not working for me. The page loads but the video does not start. I tried with Firefox and chromium. Cheers!
September 23rd, 2012 at 7:49 pm
-
lukemelia chimed in:
@Sylvain I make the other state managers a member of the application and inject them onto the router with a registered injection. However, the other approaches you listed may be perfectly good solutions depending on your app.
October 21st, 2012 at 5:11 pm
-
lukemelia chimed in:
@Aras, happy to do it if I can get the source material. A volunteer took the video and posted it, so I will need to see if I can track down the video. It plays fine for me at Cloudee, incidentally. I’m on Chrome OS X.
October 21st, 2012 at 5:14 pm
Leave a Reply