Perhaps applying the workarounds for the legacy branch and redesigning the architecture for 0.8
The Table classes are by far the most problematic classes from a usability standpoint. They are extremely flexibility if you need enterprise like tweaking, but they don't scale down. They also break a lot of conventions. - subclassing instead of using events (why? we can always subclass if we want to..) - constructors and callbacks using map's. what's wrong with public properties? What would be brilliant: - use a qooxdoo class (its properties!) as a data-model. Easy automatic sorting, formatting, etc. Nice in combination with persistance. Things like getSelectedRow() instantiate an object with those properties. (to me qooxdoo class definitions are a brilliant schema-definition language). Make it a mixin, so we can even patch existing classes to support usage in as a data model. - Unify lists, tables, trees, dropdowns, menu's as far as possible. At least on an interface level. - Sane defaults for the most common usage. Auto-sizing, resizeable, sorteable columns, one row always selected. Simple editable() toggle property; off by default. - Seperate viewer from datamodel stronger. It should be easy to use one datamodel and several view types (like icon/gallery-view, calander-view, or even single record view with next/prev buttons) Off course, this is all much easier said than done and i'm quite sure the official developers are much wiser in their choices. I really do wish they completely redesign how we work with the thing. Currently, it's over-complicated and viewer and datamodel are way too strongly integrated. (We can't use the same data-model for a tree, list, dropdown, menu, etc..) Not to bash qooxdoo offcourse. I guess i'm just getting spoiled. Greetings, Ralf 2008/4/15, Derrell Lipman <[EMAIL PROTECTED]>: > On Tue, Apr 15, 2008 at 2:38 AM, Hugh Gibson <[EMAIL PROTECTED]> wrote: > > > > but that would still give the 'blank' table for a second problem > > > when refreshing the data; rather than just a smooth update. (ie. no > > > visual impact if none of the data has changed) > > > > Sounds like you might need the fixes in > > http://bugzilla.qooxdoo.org/show_bug.cgi?id=770 and > > http://bugzilla.qooxdoo.org/show_bug.cgi?id=775 > > as well. > > > > Derrell: have you considered these for checkin at all? > > > > Hi Hugh, > > These are both indicative of the problem I stated elsewhere recently: that > the remote data model isn't asked to pre-fetch data until it's needed for > display. That's too late in many cases. The request should be issued as > soon as it becomes clear that data _will_ be needed. > > Your patches appear to cover up the problem more than fix it, if my > contention that the request for the data should be made earlier is the > correct solution to the problem. Would you agree? > > Clearly a bunch of work needs to be done with the remote table model to make > it work better. Maybe applying your patches is the right thing to do until > there's time to do that work... > > Ping me next week and I'll try to look into this in more depth. > > Cheers, > > Derrell > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
