If we can get some people (at least 2 preferably 3) to work on
ext.js+turbogears integration patterns, I would be very willing to add
some of this as a TG dependency eventually. Particularly if there
were some working code ;)
I do think that the future of web development is going to be
http:htlm+ where the + is javascript rich client libraries (ext,
dojo, yui, etc), Flex, Silverlight and whatever other "rich" client
toolkits come into vogue over the next couple of years. TurboGears 2
has to provide rich support for this new style of hybrid web/client
server applications.
So, I'm +1 on your suggestion, though if there were some enterprising
yui, dojo, or whatever, user out there who was able to make that
happen first I'd be willing to entertain the possibility of another
library.
For the moment I would suggest that none of this go into the core, but
live in an tg-ext add on library. This allows us to keep a small,
easy to understand core, with a stable API, and it allows the tg-ext
library to more closely track with updates to Ext.js. We can
certainly add a dependency to tg-ext as we go, and I'm open to making
some changes to the tg core to better accomodate ext.js integration,
but I have to admit to not quite knowing what those changes might be
up-front. I think most of the things suggested below, can be done
without changing the core at all.
--Mark Ramm
On Jan 19, 2008 7:24 AM, Alberto Valverde <[EMAIL PROTECTED]> wrote:
>
> Hi Daniel,
>
> Daniel Fetchinson wrote:
> > (....)
> >
> > 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.
>
> 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)
>
> > 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)
>
> >
> > 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.
>
> Alberto
>
>
>
>
>
>
> >
>
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
