Daniel Fetchinson wrote: >>> I read your post now, several times: >>> I know, that every answer, I can give now, to such a long, well >>> thought mail, >>> can't really give it the appreciation, it deserves. >>> >>> Basically, I think that you have some valid points. >>> In particular, I think, TW is great, but not the way to write >>> a rich client application. >>> >>> But if you need something for that, is it really a TurboGears >>> problem: TG can be used excellently as server side component of a rich >>> client app. >>> The widget problem for this kind application: isn't it solved better >>> by JS widget libraries like dojo's Dijit? >>> http://dojotoolkit.org/book/dojo-book-0-9/part-2-dijit-0 >>> >> My thoughts exactly. > > Right. I for one don't use TW at all any more, every client side GUI > component is handled by ExtJS and I'm sending the GUI definition stuff > in JSON from the server, i.e. the whole GUI is "dynamical". The html > only has a couple of lines of <div>'s and that's it. I actually think > this is the way of the future for rich client side applications. > There's one problem with this in the mid-term: accessibility.
I think Jorge's idea has one nice feature in that area. You can define a widget in one file that is then realizable from both python and javascript. With that ability, it's easier to create an html-driven website from the server for people who don't have javascript enabled browsers due to accessibility. The html presentation can then be manipulated, destroyed, and recreated by a javascript layer that uses the exact same widget definitions. To prevent re-inventing the wheel, I'd love to see a way to parse the dojo widget definitions from a turbogears server and generate those initial static pages that way. As you and Alberto have said, this seems outside the present goals of TW, though. -Toshio
signature.asc
Description: OpenPGP digital signature
