Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow complex data binding on ListView for sections and items #1311

Open
caspahouzer opened this issue Mar 9, 2022 · 0 comments
Open

Allow complex data binding on ListView for sections and items #1311

caspahouzer opened this issue Mar 9, 2022 · 0 comments

Comments

@caspahouzer
Copy link
Contributor

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant