Support for collections

5 views
Skip to first unread message

hbf

unread,
Jul 13, 2010, 5:49:30 AM7/13/10
to bindgen
Hi everybody!

I have a need to bind to items in a collection. Looking at the
FooBinding class generated by Bindgen, I see that there are iterator()
and listIterator() methods in a list binding. It is not clear to me
how I can use these to bind, for example, to the third item in a list.
iterator().next() always points to the first one, regardless of how
many times I call it. What I am looking for is something like

new FooBinding().list().itemAt(2)

Also, I need this to be read- and writable, so get() and set() should
work on it.

Is this already supported (and I can't see the wood for the trees)? If
not, is there an interest in adding this? I would try to help where I
can.

Many thanks,
Kaspar

P.S. For the sake of clarity, here is my actual use case: In a UI, I
have a panel that draws a list of items. The list is from a domain
object d, accessible via d.getList(). When the domain object d
changes, the panel gets magically notified and in order to refresh
itself, removes the sub-views of all the items of the old list and
subsequently adds sub-views for the items in the current list. My sub-
view is not constructed with the item itself (d.getList().get(2) as an
example) but instead with a "model" for the item – and this is where I
want to use the bindgen mechanism to say something like new
DBinding().list().itemAt(2).

Stephen Haberman

unread,
Jul 13, 2010, 10:03:37 AM7/13/10
to bin...@googlegroups.com
Hi Kaspar,

> Is this already supported (and I can't see the wood for the trees)? If
> not, is there an interest in adding this? I would try to help where I
> can.

This functionality isn't available but seems like it should be doable.

If anything I think having custom per-binding base classes would be a useful
feature, and `List` could just have it's own out-of-the-box custom base class.
Dunno, let me look in to it.

> When the domain object d changes, the panel gets magically notified
> and in order to refresh itself, removes the sub-views of all the items
> of the old list and subsequently adds sub-views for the items in the
> current list.

Thanks for including the use case--I'm really curious about what exactly should
happen. Let me try a concrete example and hopefully I won't be too slow to
understand what you're trying to do.

Company c = // get from some where
List<Employee> ees = c.getEmployees(); // this is what you want a binding for

// so make a company binding
CompanyBinding cB = new CompanyBinding(c);
// get ListBinding for employees
ListBinding eesB = cB.employees();

// show the company's ees on the screen
ListUiWidget w = // get from some where
w.setModel(eesB);

// Inside ListUiWidget.render():
List itemsInList = model.get(); // returns List<Employee>
for (int i = 0; i < itemsInList; i++) {
Object itemI = itemsInList.get(i);
// here is the sub-view for itemI
addUiForModel(itemI);
}

Hm. So...yeah, here each UI sub-view is getting the real Employee object, which
it could read getters/setters from, but you're saying is not powerful enough to
out and out, say, replace the 2nd EmployeeA with a different EmployeeB in its
place?

What happens if your `Company` model changes and there is no longer a 2nd or
3rd employee in the list? If the sub-view had gotten a binding from `itemAt(2)`
or `itemAt(3)`, they those bindings now just return null?

You mentioned new sub-views are added when the `Company` changes--wouldn't the
entire `ListUiWidget.render` re-run?

Just trying to understand the expected behavior you want--sorry that I'm not
getting it right away.

- Stephen

Reply all
Reply to author
Forward
0 new messages