> > 3. Let's pick a well-designed, robust and reliable javascript library > > and add functionally to tg that helps integrating it to any tg project. > > Users would have to write their javascript themselves but tg would > > automate some or most of the typical tasks that one needs to do > > in order to really make sure the client and server plays nicely together. > > This means that only minimal javascript code has to be maintained, only > > the basic API for client/server communication. > > > > I think the best choice would be the third one and as I have mentioned > > in an earlier post the Ext.js would be an excellent choice because it's > > a mature project, 2.0 was released some time ago. It's 100% documented > > and the documentation is top quality. It's very well-designed, unlike > > most of the other js libraries. It helps create maintainable and > > scalable code. It contains widgets for just about any use case and makes > > it easy to extend these widgets to create reusable new ones. The core > > size is not very big and it's possible to easily include only those > > modules which are actually needed. And last but not least it does not > > interfere with other js libraries. > > Thanks for you elaborate post. I for one would like TG to choose a > "standard" js library to build a heavier js infrastructure around it to > support rich clients. > > I've used ExtJS too and I think it would be the best choice being very > well designed and modular; the core is not too big and integrates well > with other js libs. I'm +1 on having ExtJS as the recommended lib for TG > add-ons.
I maybe didn't emphasize enough but there are 2 issues here: one is the choice of js library and the other is all the helper tg python code and js code that makes it easy to interface the client and server. The secod issue is js library agnostic and should be so. > There's a ToscaWidgets ExtJS egg which packages version 1.something > (would be nice to upgrade it to v2) which could be used to dynamically > include the needed parts of ExtJS in the page as TW can take care of > tracking dependences between JS static files and include only the ones > needed, this is done server-side in python and could become more clever > (such and concatenating into a big file and jsminifying it on the fly > for performance) Yes, minifying should be supported out-of-the-box. The C code at http://javascript.crockford.com/jsmin.html has a python version at http://javascript.crockford.com/jsmin.py.txt > > Choosing a js library is of course just one bit the bigger bit is > > having tg components which will allow users to integrate the server > > side code with the client side. The following list is a (partial) list > > of what I think tg should provide as an interface between the python > > tg application server and the javascript client: > > > > 1. A decorator for controller methods that will only be used from > javascript. > > This has slightly different requirements then other controller methods > even > > beyond @expose('json'). For example the Ext.js library likes to attach > > certain GET variables to requests which we don't want to declare as > > keyword arguments in each and every controller method. Another example > > is that if authentication is required and authorization fails we don't > > want to redirect to the login page in these controller methods. Instead, > > an error should be sent in JSON. There are certainly other peculiarities > > associated with the fact that the controller method is exclusively used > > from javascript which warrant a special decorator for these methods. > > TG's exposed methods are designed to be reusable for different output > types, so for example, if the client requests html, the dict controllers > returns will feed a template and if it requests json the dict will be > jsonified. This can, or should be able to, be extended so when dealing > with json output a 401 (authentication required) becomes an object that > is transformed client-side into a particular js exception. The point I'm > trying to make is that ideally there needn't be methods used exclusively > for javascript, with a little more thought TG could do this > automatically behind the scenes (sort-of like expose does now) Maybe it's just me but the way I usually set up my tg app is that I have methods which are really 'views' meaning there is a template attached to them and there is an api controller whose methods only return JSON. This api controller is then used by the 'view' controllers to fetch their data. But I agree tg already knows how to deal with such a situation and only a couple of helpers are needed. > > 2. Tg exception API in JSON. Whenever a server side exception > > is raised it should be sent in a well-defined JSON object to the > requesting > > javascript client. > > > > 3. Configuration sharing between server and client. There should be a > > standard way to expose some of the configuration options that users > > set for their tg app to the client. For example configuration options > > that control the visual appearance of the app like paging lengths, > > number of columns, etc, stuff which is not CSS and is > > relevant for both the server and client and is set by the user in > > one of the configuration files like config/app.cfg. > > > > (the above were stuff which needs work in python as really part of tg, > > the stuff that comes below should be implemented in javascript) > > > > 4. A separate 'tg' namespace in javascript should be available. This > > namespace should have out-of-the-box objects for creating a client > > instance, widgets, etc, with a well-defined API for both inter-javascript > > communication as well as communicating with the tg server. > > > > I'm sure there are tons of other issues too. I have implemented some of > > the stuff above in a very preliminary way and if there is interest I > > would like to contribute it somehow but more importantly I'm looking > > for the opinion of tg users and developers alike. > > > > Does any of this make any sense? > > I like the ideas, looking forward to see TG2 move in this direction. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
