[TIMOB-10377] TiAPI: event system: Bubble defaults
GitHub Issue | n/a |
---|---|
Type | Sub-task |
Priority | Low |
Status | Open |
Resolution | Unresolved |
Affected Version/s | Release 3.0.0 |
Fix Version/s | n/a |
Components | TiAPI |
Labels | n/a |
Reporter | Blain Hamon |
Assignee | Unknown |
Created | 2012-08-09T15:28:05.000+0000 |
Updated | 2018-02-28T20:04:12.000+0000 |
Description
Once the bubble architecture is done, now begins the task of determining precise behavior. This includes:
We need to quickly identify the class of events that should bubble up.
Event field in documentation: Bubbles Decisions on which events bubble is to be done in Docs first. (Hint: UI) From Neeraj: I would like to propose the following and have the council review this specific proposal this week: All generic touch based events should bubble (touchstart, touched, click, long press, etc.) Container/View specific events should not bubble (open, close, focus, blur, post layout, scroll, etc) Bubbling should stop at the window level and not propagate to any containers that hold windows (tab, tab group, and navgroup) #2 should be done via docs as the bubbleParent property #3 Proposed: * Views by default bubble to parent view where parent.add(child) * Table rows bubble to sections * Table sections bubble to table * Views inside scrollableViews bubble to that scrollableView * Whither Navgroup?
Given that windows do not bubble, and that navGroup holds windows (which don't bubble) and should be a window, I propose that NavGroup does not bubble.
Agreed, navGroups shouldn't bubble in preparation for their eventual promotion to Window status.