Hey,
> but our code gets smaller. I have no project I haven't done that, I don't
> know about the others but it's pretty common for me doing that. That's not
> something I comfortable rewriting every time.
Its not like you have to write 20 lines of code every time. It's almost the
same size of code you have to write (see last example) so I don't think thats a
strong argument.
> the same difference between "label" and "labelPath", so I guess we should
> remove labelPath as well.
The controller does not have a label property so the problem does not exist in
that context.
> I would use it in the tree, for example. That's how I'm using the tree
> widget, that's why some while ago I asked to the tree widget to be an IForm
> class. Since it is now, it should act like a multiselected List in that
> regard.
But using a tree as a form item is not the common use case as well.
> It shouldn't be. If I can do the same thing without knowing how binding works
> isn't it better? It's a common task and should be easier to do this kind of
> stuff. Without setting delegates and such.
Sure, but offering a different API does not reduce the knowledge you need to
know to use the API.
> ListController is the only one that supports c.bindProperty("m", "model",
> null, item, id);, right? For consistences reasons I think the other
> controller should have it too.
The only controller which would make sense to have it is the tree controller
(because those two are dealing with recurring items to render). And the tree
controller already offers the same API as the list controller.
Regards,
Martin
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
