{
	"id": "127898",
	"key": "ALOY-972",
	"fields": {
		"issuetype": {
			"id": "1",
			"description": "A problem which impairs or prevents the functions of the product.",
			"name": "Bug",
			"subtask": false
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [],
		"resolution": null,
		"resolutiondate": null,
		"created": "2014-03-20T15:05:01.000+0000",
		"priority": {
			"name": "Low",
			"id": "4"
		},
		"labels": [
			"community"
		],
		"versions": [
			{
				"id": "15759",
				"description": "Alloy 1.3.1",
				"name": "Alloy 1.3.1",
				"archived": false,
				"released": true,
				"releaseDate": "2014-02-10"
			}
		],
		"issuelinks": [],
		"assignee": null,
		"updated": "2018-03-07T22:26:12.000+0000",
		"status": {
			"description": "The issue is open and ready for the assignee to start work on it.",
			"name": "Open",
			"id": "1",
			"statusCategory": {
				"id": 2,
				"key": "new",
				"colorName": "blue-gray",
				"name": "To Do"
			}
		},
		"components": [],
		"description": "Assume the following views:\r\n\r\n{code:xml|title=views/view.xml}\r\n<Alloy>\r\n  <View id=\"standardView\" />\r\n  <Require src=\"customView\" id=\"customView\" />\r\n</Alloy>\r\n{code}\r\n\r\n{code:xml|title=customView.xml}\r\n<Alloy>\r\n  <View />\r\n</Alloy>\r\n{code}\r\n\r\nThe 2 function calls in this controller should logically return views\r\n\r\n{code:xml|title=controllers/view.js}\r\n$.getView('standardView'); // returns a Ti.UI.View\r\n$.getView('customView'); // returns a controller\r\n{code}\r\n\r\n",
		"attachment": [],
		"flagged": false,
		"summary": "Alloy : Alloy.Controller.getView returns a controller when requesting a widget or remote view by ID",
		"creator": {
			"name": "lsdriscoll",
			"key": "lsdriscoll",
			"displayName": "Lee Driscoll",
			"active": true,
			"timeZone": "Europe/London"
		},
		"subtasks": [],
		"reporter": {
			"name": "lsdriscoll",
			"key": "lsdriscoll",
			"displayName": "Lee Driscoll",
			"active": true,
			"timeZone": "Europe/London"
		},
		"environment": "--Titanium--\r\nTi SDK 3.2.2.GA\r\nAlloy 1.3.1\r\n\r\n--Deployment--\r\nAndroid\r\nGoogle Nexus 5\r\n\r\n--OS--\r\nDebian 7",
		"comment": {
			"comments": [
				{
					"id": "298410",
					"author": {
						"name": "skypanther",
						"key": "skypanther",
						"displayName": "Tim Poulsen",
						"active": true,
						"timeZone": "America/New_York"
					},
					"body": "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').\"\n\nIn essence, you can think of the <Require> 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.\n\n\n\n\n\n",
					"updateAuthor": {
						"name": "skypanther",
						"key": "skypanther",
						"displayName": "Tim Poulsen",
						"active": true,
						"timeZone": "America/New_York"
					},
					"created": "2014-03-24T14:35:01.000+0000",
					"updated": "2014-03-24T14:35:01.000+0000"
				},
				{
					"id": "298422",
					"author": {
						"name": "lsdriscoll",
						"key": "lsdriscoll",
						"displayName": "Lee Driscoll",
						"active": true,
						"timeZone": "Europe/London"
					},
					"body": "Hi Tim,\n\nI'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.\n\nIn my opinion, a better API would be for consistent behaviour of the getView method and the introduction of a getController method.\n\nAn 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.",
					"updateAuthor": {
						"name": "lsdriscoll",
						"key": "lsdriscoll",
						"displayName": "Lee Driscoll",
						"active": true,
						"timeZone": "Europe/London"
					},
					"created": "2014-03-24T16:15:04.000+0000",
					"updated": "2014-03-24T16:15:04.000+0000"
				},
				{
					"id": "305708",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~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.\r\n\r\nThat 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 <Require> and <Widget> 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.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2014-05-20T16:44:31.000+0000",
					"updated": "2014-05-20T16:44:31.000+0000"
				}
			],
			"maxResults": 5,
			"total": 5,
			"startAt": 0
		}
	}
}