[ALOY-152] Add an Include and Require element see description
GitHub Issue | n/a |
---|---|
Type | Story |
Priority | High |
Status | Resolved |
Resolution | Fixed |
Resolution Date | 2012-08-07T21:48:05.000+0000 |
Affected Version/s | 2012 Sprint 16 |
Fix Version/s | 2012 Sprint 16, Release 3.0.0 |
Components | Runtime, XML |
Labels | n/a |
Reporter | Russell McMahon |
Assignee | Unknown |
Created | 2012-07-30T23:54:27.000+0000 |
Updated | 2018-03-07T22:26:06.000+0000 |
Description
After having a lengthy discussion with Tony and Rick we may want to support both an Inculde and a Require element as the two elements provide quite disparate featues. Rick or Tony feel free to expand if you think I missed something.
index.xml
Would take the markup that is in myMarkup.xml and make that markup avaialable as it is under it's parent element "win1". This is good for quick reuse of fragments of markup (XML). If say within myMarkup.xml you had a Button say with id "btn1" then within the index.js controller the Ti.UI.Button proxy is accessed through "btn1". There is no associated style
On the other hand
index.xml
Would take the controller (trifecto) and add that to the index.js controller. Styles and the source controller myView.js of myView is maintained. It's like a var view1 = require("myView").create() being done automatically for you and the view hierarchy still under "win1". If myView had a Button with id "btn1" In index.js controller the developer would access the button through "view1.btn1". The advantage here is trifecto reuse and never any id collisions. If the name attribute is missing we can use the view name.
From Rick B
Include:
https://gist.github.com/3219597
Require:
https://gist.github.com/3219595
other suggestions
<!-- for widgets -->
<Require widgetId="widgetId"/>
Originally from Russell McMahon: Since both widgets and views will use the Require element we should have a type attribute. If type is missing default to type="view"
OK, but we'll need to use something else for the widget id, since *id* is reserved for Alloy use. How about we use *src* for both cases and let the *type* determine how each should be handled?
option #1
I actually like the idea of doing this initially:
option #2
but it starts introducing more reserved keywords. It's also not as flexible as using *type* if we ended up adding more types. But... man does it look pretty, clean, and expressive. I don't know, I might be talking myself back into option #2 as I'm typing. Thoughts? Also, as far as
An important distinction is that
Option #1 looks to be best.