Titanium JIRA Archive
Alloy (ALOY)

[ALOY-883] Support proxy-like elements in Alloy widget/require child view-elements

GitHub Issuen/a
TypeNew Feature
PriorityMedium
StatusClosed
ResolutionWon't Fix
Resolution Date2014-01-20T21:48:08.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsXML
Labelsalloy, children, require, views, widgets
ReporterFokke Zandbergen
AssigneeShak Hossain
Created2013-11-22T08:45:10.000+0000
Updated2014-01-21T05:21:48.000+0000

Description

Comments

  1. Ronald Treur 2013-11-22

    I might misunderstand this completely Fokke, so just taking a shot here. I get the impression you simply want an extra element to group other UI elements, but perhaps without adding an extra UI layer? If correct, then something like the example below might make sense. This Container is to behave like a basic View in many ways, except when rendering it, then it should: A) simply get out of the way and directly render its children, or B) if the widget didn't actually "do" anything with it, it's children should not be rendered at all 
     
   <Alloy>
     <Window>
       <Widget id="myWidget" src="myWidget">
         <Label id="childA" />
         <Container id="someproxy">
           <Label id="childB1" />
         </Container>
         <Container id="anotherproxy">
           <Label id="childC1" />
           <Label id="childC2" />
         </Container>
         <Label id="childD" />
       </Widget>
     </Window>
   </Alloy>
    If I'm completely off here, please clarify ;-)
  2. Fokke Zandbergen 2013-11-22

    [~ronaldtreur] yes, you could do it like that as well, having just a single <Container /> element for this purpose, but then at least another attribute then id should be used to name it, because that's exactly what I find non-descriptive about the referenced example in the Alloy repo. I'd rather name it through the tag name, because I think that is most clear.
  3. Ronald Treur 2013-11-22

    I agree that custom semantic tags would trump non-descriptive ones! Then by default these non-standard elements should not render, simply let the widget figure out what to do with it. If implementing custom tags proves difficult, then using a single new element (e.g. Container) with an id might prove a nice solution in the interim I guess? Support for both would nicely mimic HTML 5, which might be a good thing since this lowers the learning curve for a great many developers.
  4. Tony Lukasavage 2014-01-20

    How would Alloy identify a tag as a container to be passed as a named argument to children versus being just another UI element it's supposed to render?
  5. Fokke Zandbergen 2014-01-20

    There would be no other way then assuming it is when the tag is unknown and there's no module or ns attribute.
  6. Tony Lukasavage 2014-01-20

    [~fokke] there's no way to determine that the tag is "unknown". Alloy always defers to its default renderer, which is how it is able to automatically start using new Titanium APIs when they are introduced. Since this is essentially impossible in its current incarnation I'm going to close this for now. If an alternate solution arises that does not require arbitrary tags to be interpreted in a specific way, I'll re-open it.
  7. Fokke Zandbergen 2014-01-21

    Makes sense. I don't see a way that wouldn't be a terrible hack as well.

JSON Source