{
	"id": "109842",
	"key": "ALOY-525",
	"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": [
			{
				"id": "15404",
				"description": "Alloy 2.0.0",
				"name": "Alloy 2.0.0",
				"archived": false,
				"released": false
			}
		],
		"resolution": null,
		"resolutiondate": null,
		"created": "2013-02-18T09:05:41.000+0000",
		"priority": {
			"name": "Medium",
			"id": "3"
		},
		"labels": [],
		"versions": [],
		"issuelinks": [],
		"assignee": null,
		"updated": "2018-03-07T22:26:00.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": [
			{
				"id": "12326",
				"name": "XML",
				"description": "View XML and parsing"
			}
		],
		"description": "Right now, if you have a set of XML code in your view that needs to be conditionally executed (either platform, formFactor, etc) you have to add the same logic on each tag in the group or be forced to wrap in a View tag.  Wrapping in a view tag is as performant on certain platforms like Android where the view hierarchy depth is sensitive / limited.  \r\n\r\nI'd like to introduce a new tag (IF) that will make this much easier and more capable of performing more dynamic structures.\r\n\r\nThis should support both the existing conditionals: platform and formFactor.  I'd like to also introduce a cond attribute whereby you can add additional JS logic or variable which which be used to evaluate the block.\r\n",
		"attachment": [],
		"flagged": false,
		"summary": "Add support for new tag to group many blocks of XML code together easier",
		"creator": {
			"name": "jhaynie",
			"key": "jhaynie",
			"displayName": "Jeff Haynie",
			"active": false,
			"timeZone": "America/Los_Angeles"
		},
		"subtasks": [],
		"reporter": {
			"name": "jhaynie",
			"key": "jhaynie",
			"displayName": "Jeff Haynie",
			"active": false,
			"timeZone": "America/Los_Angeles"
		},
		"environment": null,
		"comment": {
			"comments": [
				{
					"id": "247373",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "in commit: https://github.com/jhaynie/alloy/commit/62b70981ba11cf985a31b9133117f9ebc8d0e56b",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2013-04-12T23:09:36.000+0000",
					"updated": "2013-04-12T23:09:36.000+0000"
				},
				{
					"id": "288907",
					"author": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"body": "I'm going to reserve this for 2.0 and likely do so via some templating engine. Rather than reinvent the wheel, and the inevitable deluge of feature requests that will follow something like this, I'll likely lean on EJS or something similar, with the ability for developers to plug in their own templating engines before the Alloy compile step.",
					"updateAuthor": {
						"name": "tlukasavage",
						"key": "tlukasavage",
						"displayName": "Tony Lukasavage",
						"active": true,
						"timeZone": "America/Los_Angeles"
					},
					"created": "2014-01-20T22:35:58.000+0000",
					"updated": "2014-01-20T22:35:58.000+0000"
				}
			],
			"maxResults": 2,
			"total": 2,
			"startAt": 0
		}
	}
}