Allow complex data binding on ListView for sections and items

[caspahouzer]

As per ALOY-609, ListSection is the UI component which is in charge of automatically populating a ListView with ListItems via a data bound model or collection. So the dataCollection needs to be set at the component, not at the :

<ListView id="list" defaultItemTemplate="title">
        <Templates>
            <ItemTemplate name="fullItem" height="70">
                <ImageView bindId="image" class="image"/>
                <Label bindId="title" class="title text-and-image"/>
                <Label bindId="subtitle" class="subtitle text-and-image"/>
            </ItemTemplate>
            <ItemTemplate name="titleAndSub" height="70">
                <Label bindId="title" class="title"/>
                <Label bindId="subtitle" class="subtitle"/>
            </ItemTemplate>
            <ItemTemplate name="title" height="50">
                <Label bindId="title" class="title"/>
            </ItemTemplate>
        </Templates>

        <ListSection id="section" dataCollection="info" dataTransform="doTransform">
            <ListItem template="{template}" title:text="{title}" subtitle:text="{subtitle}" image:image="{image}"/>
        </ListSection>
    </ListView>

It would be nice to be able to support complex collections, or multiple collections, in order to be able to create a section/item structure directly from a complex data model. Off the top of my head, there's probably 2 ways this can be achieved.

proposed solution A

Resolving ALOY-614 would allow developers to use dynamically defined dataCollection XML attributes in their views. This would in turn allow you to define a data bound collection as a result of a prior dataCollection. For example:

<ListView id="list" defaultItemTemplate="title" dataCollection="someCollection">
    <Templates>
        <!-- define templates here as usual -->
    </Templates>

    <ListSection id="section" headerTitle="{title}" dataCollection="{nestedCollectionFromSomeCollection}">
        <ListItem template="{template}" title="{title}"/>
    </ListSection>
</ListView>

proposed solution B

Develop a distinct convention for structuring of complex data such that it can all be handled internally by Alloy and the structure is just created automatically. For example, this pseudo-model shows a convention we might create in order for a to understand that it needs to lay out the data in sections first, then items within each section:

{
    viewProp: 'just some property at the ListView level'
    sections: [
        {
            title: 'some title, would be bound to this instance of ListSection'
            items: [
                {
                    title: 'another title, would be bound to this instance of ListItem in the containing ListSection',
                    template: 'someTemplate'
                },
                // ...
            ]
        },
        // ...
    ]
}

and the above pseudo-model would be leveraged in XML as such to create a section for each entry in the sections array, and an item for each entry in that section's items array.

<ListView id="list" defaultItemTemplate="title" dataCollection="thePseudoModel">
    <Templates>
        <!-- define templates here as usual -->
    </Templates>

    <ListSection id="section" headerTitle="{title}">
        <ListItem template="{template}" title="{title}"/>
    </ListSection>
</ListView>

• option B will be modeled closely after the ListView Titanium API itself, being obviously a much smaller, cleaner subset as Alloy will already be taking care of styling, eventing, and templating for you.
• My initial thought is option B as it makes for cleaner markup and to me just seems like the appropriate solution. Alloy to this point has been pretty flexible in terms of letting developers manipulate it to achieve goals. This seems like one particular situation where some defined convention would make things a lot easier for everyone. Pushing the "ugliness" to the model makes more sense than pushing it into the markup.
• I'm not seeing it, but I am making anything unnecessarily difficult for developers if I go with option B? It makes some assumptions based on the data model, but I don't see anything in it that inherently limits functionality.
• option A would be quicker, but IMO, that's about the only thing it has going for it. I would prefer not to nest multiple collections and would instead prefer to make intelligent use of one. It will make for cleaner, more performant generated code and will require less Backbone-to-Alloy wiring.