update
After 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.
<Alloy>
<Window>
<RightNavButton>
<Button/>
</RightNavButton>
<!-- the rest of the window's view hierarchy -->
</Window>
</Alloy>
While 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.
APIs to be covered in this ticket
* *Ti.UI.Window*
** leftNavButton
** rightNavButton
** titleControl
* *Ti.UI.TableView*
** footerView
** headerPullView
** headerView
** search
Additional APIs will be covered in future tickets.
original
Right now to set a property that relies on another UI component, like rightNavButton for Windows, you still need to do so in code:
$.someWindow.rightNavButton = Ti.UI.createButton({
title: 'press me'
});
What 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:
<Window rightNavButton="someButton">
<Button id="someButton" title="press me"/>
</Window>
In 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:
<Window rightNavButton="someButton"/>
<Button id="someButton" inViewHierarchy="false" title="press me"/>
The *inViewHierarchy* attribute, when set to false, would indicate that the UI component is not to be added to the view hierarchy by Alloy.
This 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...
@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. Having 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. Great feedback Fokke. I think you've officially switched me back.
As I continue to implement and test, I found another plus side of the
@Tony You're welcome! And great thinking on the
platform
andformFactor
thing!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.
The rightNavButton markup hasn't been implemented yet for popovers. I created an issue for that ( TC-1759), in the wrong group (Titanium Community)