Hi. I don't know if you're right.
I for one hate REST. It's at best cryptic. Qooxdoo provides a rich APi for POST-ing to server-side services, which, just in case you absolutely need REST, can be used to call REST services too. In most of the apps, you only use the plain old standard widgets which qooxdoo provides out of the box. I often prefer to combine some widgets right where I need them, rather than create a new widget, since this is so easy to do with qooxdoo - not what some coworkers of mine like to do, though, but they too appreciate the easiness of creating new widgets using qooxdoo. What I miss most in qooxdoo is a file upload widget which should be part of qooxdoo, rather than a contrib. We are just fighting with this problem right now, and it's not that easy to place a control on a form and make it look at least to some extent like it's part of qooxdoo. Other than that and charting, however, there's nothing I really missed out on qooxdoo until now. You have to consider one more thing. Qooxdoo isn't meant to be a complete, server- and client-side framework, just a client-side framework. Therefore, it can't provide some of the features you are asking for out of the box. Still, with what it already provides, you can easily roll your own, depending on what server-side technology you use. We're on the second project with qooxdoo, for a different customer, with different requirements. For both this project and the previous one we had to style the application differently - the app we are doing now will require the ability to change themes at runtime. Prefabricated themes wouldn't have worked in either case. Richer readymade themes would be a marketing advantage, IMO, not a technological plus. All in all, I'm quite happy with qooxdoo. I'm happy with its declared scope, and with the way it covers it. I'd rather see less rich widgets than other frameworks provide, than being tied to a particular server-side technology or even specific programming model on the client. As long as I work with de facto standard JSON RPC requests, I can easily change both the UI and the server app independently, and I get a rich interface for 3rd party apps for free. I'm readily willing to sacrifice somewhat richer widgets, which I'd anyway use only on special occasions, or a slightly easier programming model on the server or the client, as long as I can stick to standards and keep the apps I create open for extension and integration with other apps. Since I started programming, I discovered that frameworks are treacherous. The easier a framework makes easy things, the harder it makes hard things. IMO, qooxdoo has struck the right balance, by properly delimiting its scope, and making things as good and open as possible within this scope. I'd rather see it go on the same way, even if this means slower development. Code quality is an insidious beast: it doesn't bite your ass right from the start, but when it does, it's painful. On the long term, I'd rather stick with code quality than with flashy widgets, which I'd use only seldomly anyway. Other than that , I think that. with the advent of html 5, qooxdoo will have a lot more to integrate than just flashy new widgets. I suppose that as far as the widgets library goes, we will be stuck with the current set, until the marvelous new features promised by html 5 will be integrated. On the other hand, it's likely that massive browser support for html 5 will take some time, since corporate users still use mostly IE. So I don't know, maybe there will be time for adding some new widgets to the franework, like canvas, charting or file upload? All in all, IMO it's not development speed or any other technology-related issue that's a problem for qooxdoo, it's marketing. Qooxdoo is the new kid on the block, it has to get to be seen. Qooxdoo booths at some specialized conferences, some (more frequent) articles about qooxdoo in specialized ezines or printed media, some ready made built with qooxdoo logos to integrate in your application, stuff like this, would work wonders, IMO, in opening the path for sponsored development of new features. Still, I'd rather see added stuff as contribs than see insufficiently polished or integrated code seep into qooxdoo's framework code. br, flj ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
