OK, I would like to see anyone else backing up you in that decision, because
until now its been many in favor of modelPath and just you in favor of
keeping that out.
I've developed apps in html(plain), extjs, qooxdoo, apf, sproutcore. And
qooxdoo is the only one that doesn't support what I'm asking here.
And if you look what qooxdoo has to offer(playground, mobile, demobrowser,
widget set, stability, architecture) it is a lot more than others offer
right now, but even so it attracts less developers than other frameworks do.
Why is that?
IMHO, that's because qooxdoo is harder to use, and slower to develop
something with.
That's just my opinion, but I thought I should write something here because
others developers can be switching to other frameworks because of those
things too and in the end I really want qooxdoo to succeed.
On Fri, Sep 9, 2011 at 3:35 AM, Martin Wittemann
<[email protected]>wrote:
> 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
>
------------------------------------------------------------------------------
Doing More with Less: The Next Generation Virtual Desktop
What are the key obstacles that have prevented many mid-market businesses
from deploying virtual desktops? How do next-generation virtual desktops
provide companies an easier-to-deploy, easier-to-manage and more affordable
virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
