{
"id": "104931",
"key": "ALOY-382",
"fields": {
"issuetype": {
"id": "4",
"description": "An improvement or enhancement to an existing feature or task.",
"name": "Improvement",
"subtask": false
},
"project": {
"id": "11113",
"key": "ALOY",
"name": "Alloy",
"projectCategory": {
"id": "10400",
"description": "Tools for developing applications",
"name": "Tooling"
}
},
"fixVersions": [
{
"id": "14770",
"description": "Alloy 0.3.4",
"name": "Alloy 0.3.4",
"archived": false,
"released": true,
"releaseDate": "2012-12-14"
},
{
"id": "14773",
"description": "2012 Sprint 24",
"name": "2012 Sprint 25",
"archived": true,
"released": true,
"releaseDate": "2012-12-17"
}
],
"resolution": {
"id": "1",
"description": "A fix for this issue is checked into the tree and tested.",
"name": "Fixed"
},
"resolutiondate": "2012-12-07T20:09:30.000+0000",
"created": "2012-11-14T02:42:39.000+0000",
"priority": {
"name": "High",
"id": "2"
},
"labels": [
"notable"
],
"versions": [
{
"id": "14631",
"description": "Alloy 0.3.1",
"name": "Alloy 0.3.1",
"archived": false,
"released": true,
"releaseDate": "2012-11-02"
}
],
"issuelinks": [
{
"id": "22777",
"type": {
"id": "10020",
"name": "Depends",
"inward": "is dependent of",
"outward": "depends on"
},
"outwardIssue": {
"id": "104932",
"key": "ALOY-383",
"fields": {
"summary": "inViewHierarchy markup attribute",
"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": "High",
"id": "2"
},
"issuetype": {
"id": "2",
"description": "A new feature of the product, which has yet to be developed.",
"name": "New Feature",
"subtask": false
}
}
}
}
],
"assignee": null,
"updated": "2018-03-07T22:25:40.000+0000",
"status": {
"description": "A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.",
"name": "Resolved",
"id": "5",
"statusCategory": {
"id": 3,
"key": "done",
"colorName": "green",
"name": "Done"
}
},
"components": [
{
"id": "12326",
"name": "XML",
"description": "View XML and parsing"
}
],
"description": "h2. update\r\n\r\nAfter revisiting an original idea for this ticket and a discussion with Fokke, the more expressive and perhaps purer solution would be to incorporate properties that take proxies as values as additional special markup.\r\n\r\n{code:xml}\r\n\r\n \r\n \r\n \r\n \r\n \r\n \r\n\r\n{code}\r\n\r\nWhile it might appear simpler to just imply that is the button itself, that property actually takes a Titanium.UI.View, so it could be something other than a button. And this is only one case. In order to be uniform with the other similar properties that will behave in this manner, the property name will be used as a container for the component that will eventually be its value.\r\n\r\nh4. APIs to be covered in this ticket\r\n\r\n* *Ti.UI.Window*\r\n** leftNavButton\r\n** rightNavButton\r\n** titleControl\r\n* *Ti.UI.TableView*\r\n** footerView\r\n** headerPullView\r\n** headerView\r\n** search\r\n\r\nAdditional APIs will be covered in future tickets.\r\n\r\nh2. original\r\n\r\nRight now to set a property that relies on another UI component, like rightNavButton for Windows, you still need to do so in code:\r\n\r\n{code:javascript}\r\n$.someWindow.rightNavButton = Ti.UI.createButton({\r\n title: 'press me'\r\n});\r\n{code}\r\n\r\nWhat would be good would to be able to specify this stuff in markup, and thereby being able to apply styles and such in the process:\r\n\r\n{code:xml}\r\n\r\n \r\n\r\n{code}\r\n\r\nIn this situation, Alloy should be smart enough to assign the rightNavButton by the given id, and also *NOT* add someButton to the view hierarchy. If the button is specified outside of the Window though, like this:\r\n\r\n{code:xml}\r\n\r\n\r\n{code}\r\n\r\nThe *inViewHierarchy* attribute, when set to false, would indicate that the UI component is not to be added to the view hierarchy by Alloy.\r\n\r\nThis would obviously apply to more than just rightNavButton. It could apply to pretty much any property of a Titanium proxy that requires a reference to another proxy. rightNavButton, leftNavButton, searchbar (tableview), etc...\r\n\r\n",
"attachment": [],
"flagged": false,
"summary": "rightNavButton markup (and other similar properties)",
"creator": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"subtasks": [],
"reporter": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"environment": null,
"comment": {
"comments": [
{
"id": "230372",
"author": {
"name": "fokkezb",
"key": "fokke",
"displayName": "Fokke Zandbergen",
"active": true,
"timeZone": "Europe/Amsterdam"
},
"updateAuthor": {
"name": "fokkezb",
"key": "fokke",
"displayName": "Fokke Zandbergen",
"active": true,
"timeZone": "Europe/Amsterdam"
},
"created": "2012-12-07T07:29:58.000+0000",
"updated": "2012-12-07T07:31:05.000+0000"
},
{
"id": "230382",
"author": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"body": "@Fokke, your example was originally how I had planned to implement Titanium proxy properties that take other proxies as values. The reason I switched gears and went for the ID-driven solution was for the sake of uniformity and simplicity. Now each property needs its own XML notation that has a special meaning, rather than just assigning an ID to any property that takes a proxy.\n\nHaving said that, and considering that I agree with you on ALOY-383, I'm starting to shift back to my original thinking (and your current thinking) that the most expressive way to show these properties is as you put forth above. Yes, it'll be a little more documentation, but there aren't that many occurrences of these properties in the API, and it makes the markup VERY clear as to the association of components. With the ID-driven solution, a developer could potentially be searching through ID names to find the associated component. \n\nGreat feedback Fokke. I think you've officially switched me back.",
"updateAuthor": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"created": "2012-12-07T14:12:04.000+0000",
"updated": "2012-12-07T14:12:04.000+0000"
},
{
"id": "230391",
"author": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"body": "As I continue to implement and test, I found another plus side of the solution. Being able to define it as its own markup element allows developers to take advantage of the *platform* and *formFactor* attribtues as well for code reduction and optimization. SO in the the case of a rightNavButton, you could not even have it present on android, where it is not used:\n\n{code:xml}\n\n\t\n\t\t\n\t\t \n\t\t \t\t\n\t\t \t\t\t\n\t\t \t\t\n\t\t \n\t \n \n\n{code}",
"updateAuthor": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"created": "2012-12-07T16:17:50.000+0000",
"updated": "2012-12-07T16:17:50.000+0000"
},
{
"id": "230397",
"author": {
"name": "fokkezb",
"key": "fokke",
"displayName": "Fokke Zandbergen",
"active": true,
"timeZone": "Europe/Amsterdam"
},
"body": "@Tony You're welcome! And great thinking on the {{platform}} and {{formFactor}} thing!",
"updateAuthor": {
"name": "fokkezb",
"key": "fokke",
"displayName": "Fokke Zandbergen",
"active": true,
"timeZone": "Europe/Amsterdam"
},
"created": "2012-12-07T17:57:36.000+0000",
"updated": "2012-12-07T17:57:36.000+0000"
},
{
"id": "230434",
"author": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"body": "All listed APIs have been implemented with specialized markup. Examples of all can be found in the the [ui/proxy_properties test app|https://github.com/appcelerator/alloy/tree/master/test/apps/ui/proxy_properties] in the github repository.",
"updateAuthor": {
"name": "tlukasavage",
"key": "tlukasavage",
"displayName": "Tony Lukasavage",
"active": true,
"timeZone": "America/Los_Angeles"
},
"created": "2012-12-07T20:09:30.000+0000",
"updated": "2012-12-07T20:09:30.000+0000"
},
{
"id": "234549",
"author": {
"name": "rlustemberg",
"key": "rlustemberg",
"displayName": "Richard Lustemberg",
"active": true,
"timeZone": "Europe/Berlin"
},
"body": "The rightNavButton markup hasn't been implemented yet for popovers. I created an issue for that ( TC-1759), in the wrong group (Titanium Community)",
"updateAuthor": {
"name": "rlustemberg",
"key": "rlustemberg",
"displayName": "Richard Lustemberg",
"active": true,
"timeZone": "Europe/Berlin"
},
"created": "2013-01-16T04:08:46.000+0000",
"updated": "2013-01-16T04:08:46.000+0000"
}
],
"maxResults": 6,
"total": 6,
"startAt": 0
}
}
}