Hello Michael, > I love what I've seen from Qooxdoo so far, but the widget availability > confuses the hell out of me. There's three different tree implementations, > two different list implementations (three if you count the deprecated one), > and as if that where not enough, they all seem to support various different > forms of databinding. Sounds in deed confusing and should be cleand up / marked clearer what widget to use when. I hope my further answer will clear things up a bit.
> While I have some idea now what each of them does, I'm curious to know what > the way forward is (I am assuming that there is the intention to consolidate > those, because right now, the whole thing is highly inaccessible and > unsatisfying). > > qx.ui.form.List and qx.ui.tree.Tree uses the controller approach to > databinding. qx.ui.list.List and qx.ui.tree.VirtualTree work directly with a > model and delegate. Why the different approaches? The first two widgets work as plain old widgets and do render as many children as they get. Thats why they can have a data binding controller, which is outside the widget which simply creates child widgets for the container. Additionally, you can use these widgets without using data binding by creating these child widgets yourself. The other two widgets you mentioned are virtual widgets and only render the amount of children you see on the screen. Therefore, an outer controller like in the other case, can not work the same way because the child widget creation depends on the rendering of the container widget. Therefore, an inner approach is more suitable. Additionally, the virtual widgets do not work without data binding. > Along with the sparse > documentation, I cannot emphasise enough how hard I found it as a beginner > to grasp what is going on with these widgets and databinding. What kind of documentation would have helped you? Do you think some kind of overview could have worked for you? > Wouldn't it be preferrable to make all widgets virtual, and agree upon a > single way to do the databinding? Reading the mailing list I'm picking up > signs that maybe this is the intention, but it's not really clear what the > direction is here. Well, I'm not sure if thats the right way. I don't think that a gender picking select box needs to be virtual and data bound. SelectBoxes and ComboBoxes are the same as lists usually. That would increase the complexity of a qooxdoo app even more if you need to understand data binding before you can use a simple select box. > On a related note, I keep stumbling over there being no widget that supports > a) databinding and b) sortable columns. e.g. a table predating all the cool > stuff. Again, there are some references to a new table being planned, but > that's not going to happen anytime soon, is that correct? Exactly, thats the current state of development. As the current table is a well liked widget by most of the community, it is more likely that a table controller will make it into the framework than a new table in the near future. Best, Martin ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
