On Tue, Apr 15, 2008 at 10:26 AM, Ralf Nieuwenhuijsen <
[EMAIL PROTECTED]> wrote:
> 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..)
I'm not sure what you're referring to here.
>
> - constructors and callbacks using map's. what's wrong with public
> properties?
That was to maintain backward compatibility based on the way things already
worked. I did that when I implemented TreeVirtual and found that once some
things were set (i.e. by the Table constructor), it was nearly impossible to
change them, so setting them via parameters to the constructor was
required. I agree it shouldn't be necessary. Table is a fabulous piece of
work, but has too many incestuous interrelationships between its various
classes making it difficult to do some things that were not originally
considered.
>
> 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..)
I'm eagerly awaiting your contribution of code that implements what you've
suggested. It sounds wonderful! Will you have it ready in time for 0.8?
:-)
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
