[ALOY-755] Alloy dynamic styling: modify raw styles should affect new alloy controllers
|Affected Version/s||Alloy 1.2.0, Alloy 1.5.1|
|Assignee||Feon Sua Xin Miao|
DescriptionWhile reading raw styles arrays is possible in alloy 1.2, modifying them does not affect to new alloy controllers created by Alloy.createController() or Alloy.createWidget(). This is due to default styles are hardcoded when alloy code is pre-compiled to titanium. Instead of that, we have to use the new alloy method $.UI.create('component', style). But to force using $.UI.create() means to create the UI from the controller file, so all the powerful and flexibility of xml+tss files is lost. Instead of that, I suggest that modifying the raw styles overwrites the default styles hardcoded by alloy. I understand this is not a trivial feature, but I think this behavior is more in the line of what Alloy is and what means for the developers. As an example, if I have a class called "H1" and I modify it, I expect that all new components using that class will be affected and will use the new style. Related to TC-2646, the ideal would be that, if the style is in the global styles array, that style would be also inherited by every controller using that class. Discussion and examples can be found at http://developer.appcelerator.com/question/155135/alloy-dynamic-styling-access-app-raw-style-and-edit-styles
- Jan Helleman 2014-01-24 Is there any news or thoughts on this and the related issues matter? I'd like to modify styles in a mass yet localizable way. When I'd use an applyStyle kind of function I would lose most of the Alloy structuring plus it would make a mess of a code...
- Paul Hamilton 2014-07-01 I want to do this as well. Creating skins (say, a light and a dark theme) is quite cumbersome without being able to do this.
- Tim Poulsen 2015-02-10 Implementing this would require some potentially significant re-architecting of Alloy. I'm afraid it's not on our roadmap in the near-term.