[ALOY-972] Alloy : Alloy.Controller.getView returns a controller when requesting a widget or remote view by ID
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Low |
| Status | Open |
| Resolution | Unresolved |
| Affected Version/s | Alloy 1.3.1 |
| Fix Version/s | n/a |
| Components | n/a |
| Labels | community |
| Reporter | Lee Driscoll |
| Assignee | Unknown |
| Created | 2014-03-20T15:05:01.000+0000 |
| Updated | 2018-03-07T22:26:12.000+0000 |
Description
Assume the following views:
<Alloy>
<View id="standardView" />
<Require src="customView" id="customView" />
</Alloy>
<Alloy>
<View />
</Alloy>
$.getView('standardView'); // returns a Ti.UI.View
$.getView('customView'); // returns a controller
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
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.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.
[~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 throughgetView()to recurse and search by id would be much more appropriate than actually changing the existing API to do something different.