[ALOY-972] Alloy : Alloy.Controller.getView returns a controller when requesting a widget or remote view by ID
|Affected Version/s||Alloy 1.3.1|
DescriptionAssume the following views:
<Alloy> <View id="standardView" /> <Require src="customView" id="customView" /> </Alloy>
The 2 function calls in this controller should logically return views<Alloy> <View /> </Alloy>
$.getView('standardView'); // returns a Ti.UI.View $.getView('customView'); // returns a controller
- Tim Poulsen 2014-03-24
I can understand your expectation, though the actual behavior is documented. The [$.getView()](http://docs.appcelerator.com/titanium/latest/#!/api/Alloy.Controller-method-getView) entry states that it returns either a controller or view instance. And in the [Require tag](http://docs.appcelerator.com/titanium/latest/#!/guide/Alloy_XML_Markup-section-35621528_AlloyXMLMarkup-RequireElement) states "To use UI objects from the included views ... var object = $.requireId.getView('objectId')."
In essence, you can think of the
tag doing the equivalent of
Alloy.createController('customView')which in your controller you'd need to the follow with
.getView()to access the associated View. See [createController()](http://docs.appcelerator.com/titanium/latest/#!/api/Alloy-method-createController) to see it returns a controller, not a view.
- Lee Driscoll 2014-03-24 Hi Tim, I'm aware that I have described documented behaviour as a bug, maybe it would have been better for me to have listed this as an improvement. In my opinion, a better API would be for consistent behaviour of the getView method and the introduction of a getController method. An example of where this becomes obvious is when the children of a view are a mixed bag of internal and external views - for instance a form window that contains provided (e.g. Ti.UI.TextField) controls and custom ones (e.g. com.mycompany.combobox). Now, I will probably want to loop through each field and retrieve the value from each to save it to the database. With the current API, that loop will have to contains code to check whether the child view is actually an external controller so that the view can be accessed correctly, reducing the overall efficiency of the code, proving that having a consistent API makes for better OO.
- Tony Lukasavage 2014-05-20
[~lsdriscoll] it seems to me in the case that you cited that the issue is not with Alloy and its documented distinction between the return types of
getViews(), but instead with the implementation of the views/widgets you might be using. The views and widgets are meant to be self-contained, exposing an interface to them via controllers as necessary. If you have a custom widget that has a list of form fields, my expectation is that that widget would also have a simple interface for extracting the values of those fields, not that the developer using it would be expected to iterate through each one individually. Changing the Alloy API to suit poorly designed widgets is just not something we can do. That said, there are some functions on controllers that are generally only used internally by Alloy that do a bit of what you are trying to do. For example,
getViewEx(opts)will recurse through
and to find the actually top-level UI component, but it doesn't take ids. A feature request to allow
getView()to recurse and search by id would be much more appropriate than actually changing the existing API to do something different.