[TIMOB-7319] Ti API: Label, TextArea support add method on iOS only
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | High |
| Status | Closed |
| Resolution | Won't Do |
| Resolution Date | 2020-01-09T23:32:12.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | TiAPI |
| Labels | parity |
| Reporter | Arthur Evans |
| Assignee | Eric Merriman |
| Created | 2012-01-20T14:04:33.000+0000 |
| Updated | 2020-01-10T10:30:20.000+0000 |
Description
See related Q&A Item:
http://developer.appcelerator.com/question/130925/about-textaress-methodadd
Need to define which controls can/should accept children and which cannot or should not.
In my opinion ... in the documentation, there should be clear separation between different types of UI components: windows, views and controls. Here is example of how I explain UI namespace: Controls are components that are used for user interaction (selecting data values, entering data values, etc) and that can't contain other components: Label, TextField, TextArea, Button etc. There are special cases of composite control components that can contain other specific controls (so, they are also of view type). Picker->PickerColumn->PickerRow is currently the only one special case on both platforms. Views are components that are used for UI layout and that can contain other components of view or control type. There are also special composite views like TableView->TableViewSection->TableViewRow (TableViewRow is of view type so it can contain other views and controls), which means that TableViewSection and TableViewRow can't visually exist for themselves, they can only be added to TableView component. All views have different layout mechanisms and some view types are scrollable which means they can show content that is greater than their size by scrolling in different directions. Windows are components that are used for navigation. They have methods like "open" or "close" that are responsible for creating and destroying new visual surface on the screen. The most basic and main component is Window component. Beside Window, there is special composite TabGroup component that is basic navigation control. It is top level composite component that can contain only Tab components and each Tab component can contain Window component (TabGroup->Tab->Window). They are also of view type, which means other views and controls can be added to them and different layout mechanisms can be applied to them. TabGroup is restricted and can't have different layout mechanism, it's visual behavior is determined by native platform on which app runs. Anyway ... that's just basic explanation (and it can be massively improved firstly because English is not my native language :) ) but in my opinion it is much better than basic ("flat") explanation. Organization of UI components in semantically correct hierarchy can greatly improve learning curve for new developers. That way nobody would ask why can't he add TableViewRow to ScrollView, or why Tab can't be added to Picker and other great questions. Also, this way concerns are separated and developers are implicitly pushed to direction of designing applications in a way that different application parts are separated: navigation, high-level layout (that can easily be modified for different platforms and screen resolutions) and low-level controls.
This will require changes to our UI type hierarchy which are planned with our upcoming UI Layout API implementation
FWIW Mobile Web supports the add() method on all controls, including label. We have architected mobile web so that the transition mentioned by Marshall should be relatively painless.
We can take care of this issue in few different ways. We should keep it open for further discussion.
Ivan: it adds that view to the label...just as if the label were a view (in fact label inherits from view). I believe the contents of the view will sit on top of the text. As for the CommonJS thing, talk to Chris Barber. He's the one who implemented that part of mobile web.
This issue is out of date with our current supported SDK release (7.5.2.GA as of the date of closure), and out of date with mobile OS versions. If community members feel that the issue is still valid, please create a new ticket. Please reference this closed ticket number, include SDK used, comments, and code that demonstrates/reproduces the issue.
Closing ticket as it marked as
Won't Do.