{
	"id": "122795",
	"key": "ALOY-883",
	"fields": {
		"issuetype": {
			"id": "2",
			"description": "A new feature of the product, which has yet to be developed.",
			"name": "New Feature",
			"subtask": false
		},
		"project": {
			"id": "11113",
			"key": "ALOY",
			"name": "Alloy",
			"projectCategory": {
				"id": "10400",
				"description": "Tools for developing applications",
				"name": "Tooling"
			}
		},
		"fixVersions": [],
		"resolution": {
			"id": "2",
			"description": "The problem described is an issue which will never be fixed.",
			"name": "Won't Fix"
		},
		"resolutiondate": "2014-01-20T21:48:08.000+0000",
		"created": "2013-11-22T08:45:10.000+0000",
		"priority": {
			"name": "Medium",
			"id": "3"
		},
		"labels": [
			"alloy",
			"children",
			"require",
			"views",
			"widgets"
		],
		"versions": [],
		"issuelinks": [
			{
				"id": "33332",
				"type": {
					"id": "10003",
					"name": "Relates",
					"inward": "relates to",
					"outward": "relates to"
				},
				"outwardIssue": {
					"id": "111278",
					"key": "ALOY-603",
					"fields": {
						"summary": "Allow Alloy widgets to be wrapped around child elements in XML views",
						"status": {
							"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
							"name": "Closed",
							"id": "6",
							"statusCategory": {
								"id": 3,
								"key": "done",
								"colorName": "green",
								"name": "Done"
							}
						},
						"priority": {
							"name": "Medium",
							"id": "3"
						},
						"issuetype": {
							"id": "4",
							"description": "An improvement or enhancement to an existing feature or task.",
							"name": "Improvement",
							"subtask": false
						}
					}
				}
			}
		],
		"assignee": {
			"name": "shossain",
			"key": "shossain",
			"displayName": "Shak Hossain",
			"active": false,
			"timeZone": "America/Los_Angeles"
		},
		"updated": "2014-01-21T05:21:48.000+0000",
		"status": {
			"description": "The issue is considered finished, the resolution is correct. Issues which are closed can be reopened.",
			"name": "Closed",
			"id": "6",
			"statusCategory": {
				"id": 3,
				"key": "done",
				"colorName": "green",
				"name": "Done"
			}
		},
		"components": [
			{
				"id": "12326",
				"name": "XML",
				"description": "View XML and parsing"
			}
		],
		"attachment": [],
		"flagged": false,
		"summary": "Support proxy-like elements in Alloy widget/require child view-elements",
		"creator": {
			"name": "fokkezb",
			"key": "fokke",
			"displayName": "Fokke Zandbergen",
			"active": true,
			"timeZone": "Europe/Amsterdam"
		},
		"subtasks": [],
		"reporter": {
			"name": "fokkezb",
			"key": "fokke",
			"displayName": "Fokke Zandbergen",
			"active": true,
			"timeZone": "Europe/Amsterdam"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "280718",
					"author": {
						"name": "ronaldtreur",
						"key": "ronaldtreur",
						"displayName": "Ronald Treur",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "I might misunderstand this completely Fokke, so just taking a shot here.\n\nI get the impression you simply want an extra element to group other UI elements, but perhaps without adding an extra UI layer? If correct, then something like the example below might make sense. This Container is to behave like a basic View in many ways, except when rendering it, then it should:\n\nA) simply get out of the way and directly render its children, or\nB) if the widget didn't actually \"do\" anything with it, it's children should not be rendered at all\n\n{code:xml} \n<Alloy>\n  <Window>\n    <Widget id=\"myWidget\" src=\"myWidget\">\n      <Label id=\"childA\" />\n      <Container id=\"someproxy\">\n        <Label id=\"childB1\" />\n      </Container>\n      <Container id=\"anotherproxy\">\n        <Label id=\"childC1\" />\n        <Label id=\"childC2\" />\n      </Container>\n      <Label id=\"childD\" />\n    </Widget>\n  </Window>\n</Alloy>\n{code}\n\nIf I'm completely off here, please clarify ;-)",
					"updateAuthor": {
						"name": "ronaldtreur",
						"key": "ronaldtreur",
						"displayName": "Ronald Treur",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2013-11-22T11:41:53.000+0000",
					"updated": "2013-11-22T11:41:53.000+0000"
				},
				{
					"id": "280719",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "[~ronaldtreur] yes, you could do it like that as well, having just a single {{<Container />}} element for this purpose, but then at least another attribute then {{id}} should be used to name it, because that's exactly what I find non-descriptive about the referenced example in the Alloy repo. I'd rather name it through the tag name, because I think that is most clear.",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2013-11-22T12:03:43.000+0000",
					"updated": "2013-11-22T12:03:43.000+0000"
				},
				{
					"id": "280720",
					"author": {
						"name": "ronaldtreur",
						"key": "ronaldtreur",
						"displayName": "Ronald Treur",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "I agree that custom semantic tags would trump non-descriptive ones! Then by default these non-standard elements should not render, simply let the widget figure out what to do with it.\n\nIf implementing custom tags proves difficult, then using a single new element (e.g. Container) with an id might prove a nice solution in the interim I guess?\n\nSupport for both would nicely mimic HTML 5, which might be a good thing since this lowers the learning curve for a great many developers.",
					"updateAuthor": {
						"name": "ronaldtreur",
						"key": "ronaldtreur",
						"displayName": "Ronald Treur",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2013-11-22T12:26:28.000+0000",
					"updated": "2013-11-22T12:26:28.000+0000"
				},
				{
					"id": "288877",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "How would Alloy identify a tag as a container to be passed as a named argument to {{children}} versus being just another UI element it's supposed to render?",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2014-01-20T21:22:15.000+0000",
					"updated": "2014-01-20T21:22:15.000+0000"
				},
				{
					"id": "288879",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "There would be no other way then assuming it is when the tag is unknown and there's no `module` or `ns` attribute.",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2014-01-20T21:26:17.000+0000",
					"updated": "2014-01-20T21:26:17.000+0000"
				},
				{
					"id": "288887",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "[~fokke] there's no way to determine that the tag is \"unknown\". Alloy always defers to its default renderer, which is how it is able to automatically start using new Titanium APIs when they are introduced. \r\n\r\nSince this is essentially impossible in its current incarnation I'm going to close this for now. If an alternate solution arises that does not require arbitrary tags to be interpreted in a specific way, I'll re-open it.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2014-01-20T21:48:08.000+0000",
					"updated": "2014-01-20T21:48:08.000+0000"
				},
				{
					"id": "288970",
					"author": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"body": "Makes sense. I don't see a way that wouldn't be a terrible hack as well.",
					"updateAuthor": {
						"name": "fokkezb",
						"key": "fokke",
						"displayName": "Fokke Zandbergen",
						"active": true,
						"timeZone": "Europe/Amsterdam"
					},
					"created": "2014-01-21T05:21:48.000+0000",
					"updated": "2014-01-21T05:21:48.000+0000"
				}
			],
			"maxResults": 7,
			"total": 7,
			"startAt": 0
		}
	}
}