Hi Olivier, The plunk was a quick demo to illustrate a point. It is, and never was meant as production code. It was a tool to demonstrate an issue is was having in a whole different setting! I will go over your answer inline:
Took a quick look at your Plunk and I think the way you use the promise if > a bit off > In a sense, I'd be ready to say that no way is wrong, but I'm just not too > sure about it for now > Ok, can you explain me why you would think this? Promises are made to make async/eventdriven code easier, and in my opinion, that's just what's going on. > > You never should have to chain .then() in your template, it just doesn't > make sense to me > Also, but this is mostly a preference I have, I'd rather not bind a > promise to the template directly, or even a factory, but that's "me" > I agree, but as stated earlier on, this is a quick demo, not a full-fledged and tested production thing. The issue I had, was that it didn't update correctly without the then. The code that led to this sample handled it all in the controller. The problem was the same. > It is important to note that previous versions of Angular supported > binding a promise directly in the template and it was automatically > unwrapping the promise for you, this showing the result in the template, > but this isn't true anymore. That's just one more reason not to bind a > promise to the Tpl. > I know. I never liked the automatic unwrapping, and even did extra work to avoid it. The current way is much clearer, and easier to explain. > The method you call from the template should live on the $scope created by > your controller, and let that method do the work it needs and interect with > your factory/promises and what not. When the promise is resolved, then you > update whatever you need on the $scope object so it's reflected in your UI > Here I completely disagree with you. At least for the use-case I need it for. For a simple timeout I would never use a construct like this. The use of a factory is to encapsulate the business logic. The use of a controller is to hook up everything to the UI. In the real program, the object that's returned from the promise in the factory is way more complex, and I need a couple of methods that kick in some indeed complex logic. That logic must remain entirely in the factory, and not leak into the controller. the methods that trigger those logic are returning a promise, so the controller can hook up the needed UI-changes, however, they still should work without consuming this promise! In your sample, you are transferring part of the business logic to the controller. Just one example is that you you are setting the default of done to false. In my opinion that's a decision that should reside in the factory! To show you what I mean I updated the plunk <http://goo.gl/7yLovJ>. Have a look at the controller, no change there, it just hooks up the model, and the (business) logic to the view. The factory has some added stuff, but this does not change the way the controller or the view interact with it. The real factory does a whole lot more. It encapsulates an complete client side login system. it is pulling in scripts, fires a couple of requests and pulls in data from different sources. I don't want to give controllers/directives that consume this factory anything else then the end result, and a way to kick off some extra functionality. Now you know this, how would you solve this? I really want to know. If I'm embarking in the wrong direction, I rather know now! Regards Sander -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.
