[ALOY-504] Remove event listeners on dataFunction
|Components||Models, Runtime, XML|
|Labels||alloy, bind, bindings, controller, data, model, views|
|Assignee||Feon Sua Xin Miao|
DescriptionThis issue is related to the following topic on Google Groups: https://groups.google.com/forum/?fromgroups=#!topic/appc-ti-alloy/7TKs1YiLrNk It asks for:
Exposing the Alloy-generated data-binding function.
Making the function compatible to consume any iterable array or object.
Having of the option to not automatically add this function as an event listener to model or collection, so you can decide when to call it, using whatever data you like.These small changes allow for a more flexible use of the data-binding in Alloy, while maintaining the ready-for-use approach available right now.
- Fokke Zandbergen 2013-04-23
The 2nd point of this issue can be dropped. The first and last are already in Alloy 1.1, now we have the
dataFunctionattribute. The 2nd point now has it's own issue with more details and examples: TC-2188.
- Tony Lukasavage 2013-04-23 ACtually, the 3rd point is not resolved. Although you can expose the binding function with an explicit name, it is still always fired on your behalf, you just have the ability to do it manually as well. I'm pondering now if defining the name should imply that you want to be in full control of when binding fires, or if a secondary attribute should indicate that. I guess my concern is that if you are manually defining the name of the function and when it will be called, why bother doing the binding in markup at all? Why not just do it all in code?
- Fokke Zandbergen 2013-04-23
I would say that the very reason for wanting to name the data-binding method is that you want to call it yourself. So yes, I suggest to drop the listeners if
dataFunctionwas used. Why bother you ask? Well, because you want your views to show all there is to it and not have some UI hidden away in the controller.
- Jick Steen 2013-06-16 +1 for dropping the listeners if dataFunction is used.
- Tim Poulsen 2014-05-14 I'm trying to plan out time for this ticket. Am I correct that in the end, all that's being asked for is removing the listeners on dataFunction? Since that could potentially break existing apps, would you see any issues with creating a new function that didn't have listeners and keeping them on dataFunction()?
- Fokke Zandbergen 2014-05-15
I gave a detailed description in a new ticket: ALOY-639
I think we should have tackled both issues together, as now indeed we might break apps unless we introduce a new attribute and I'd hate that. Actually I doubt how many people actually use
dataFunction. I don't, because I don't see much use in it without the additional functionality described in ALOY-639, since for what it does now you could as well just trigger a
fetchor other event on the collection. So, if it was up to me... just change the behavior of
dataFunctionto meet ALOY-639 and add a breaking note to the release notes. It'll be just a few apps.
- Junaid Younus 2015-06-15 I know this ticket is quite old, but point number 2 in the initial request would be a huge bonus. It's really awkward having to work with Alloy Models all the time for dataCollection to work. Sometimes that's just not possible with a certain APIs that you get (we use the sqlrest adaptor with Alloy Models), which means you then have to resort to some nasty workarounds throughout your project. Being able to pass in a simple array would be amazing and a huge time saver.
- Fokke Zandbergen 2015-06-15 [~jyounus] I agree it would be a great improvement, which is now requested under ALOY-639. If you have time to give it a go, the required changes should be in https://github.com/appcelerator/alloy/blob/master/Alloy/commands/compile/compilerUtils.js#L914.
- Junaid Younus 2015-06-16 Thanks for your reply Fokke! This look promising. I won't have time to checkout the current progress on Alloy, I'll have to wait until those changes are inside the latest stable Alloy update. But really looking forward to stop using these workarounds for binding data!