Hi folks, sorry, this will be a long post :) With the release of tg2 in the near future tg has evolved into a robust, reliable, well-designed and easy to use web development framework. It greatly reduces the work of developers on the server side of web applications by automating common tasks as well as providing sane defaults.
However web applications these days are not server side applications but rather client/server applications. Traditionally web developers did not need to worry about client side issues because the clients, web browsers, were assumed to do their job on their own. These days client side development is just as an integral part of web development as writing server side code. Unfortunately tg does little to ease this part of the development. (Apart from a couple of ajaxish forms, which will soon be gone and moved into toscawidgets as far as I know. Even if they stayed this would not really address the issue of a full stack client application framework component for tg.) I believe it would be a major boost to tg and would elevate it to the position of *the* best web application framework if it contained a comprehensive component for client side application development of the same great quality as the rest of tg. From what I'll say below I hope it will be clear that tg widgets + some javascript here and there is not what I have in mind but something much more comprehensive. You might ask why should it be part of tg and why shouldn't it be up to the developer to choose the tools he/she wishes for his/her client side needs? I think the success of tg is largely due to the fact that there are default components with sane defaults while it allows advanced developers to bypass these defaults and use their own toolsets if flexibility is required. Secondly, tg2 is not an uber-flexible web framework for just about anything, this role is played by pylons. The flexibility naturally gets limited in tg simply because otherwise it would be duplicating functionality found in pylons. Due to this I believe a new client side application framework should be an integral part of tg but implemented such of course that users should easily be able to bypass it if they desired. Client side applications in our case mean -- unfortunately -- javascript. I looked into what would be the best approach for tg and found these 3 choices: 1. Let's write everything in python, not a single line of javascript. The pypy project has a fully functional RPython -> javascript translator complete with a very basic client/server framework. Although this is a very interesting direction and one that actually works (I used it) the huge overhead that comes with pypy probably doesn't worth it at this time. http://codespeak.net/pypy/dist/pypy/doc/js/using.html 2. Using the pyjamas project. This is also an interesting approach, basically porting the Google Web Toolkit from java to python. We would use a subset of python which would get translated to javascript. Unfortunately pyjamas is not a very mature project and development is extremely slow. http://code.google.com/p/pyjamas/ 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. 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. 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? Cheers, Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
