BTW, this discussion should probably be moved to turbogears-trunk as it's about what will happen in TG2 (and possibly 1.1) but we don't expect to change anything in the stable version of TurboGears...
On Jan 6, 2008 3:47 PM, Daniel Fetchinson <[EMAIL PROTECTED]> wrote: > > > I think we probably have 2 different use cases that need to be covered: > > > > 1) Adding a few simple ajax helpers, and some basic javascript stuff > > 2) Adding rich javascript based interfaces with complex widgets, and > > all that kind of thing > > Exactly. > > > Case 1 is handled by pretty much all of the libraries, but they aren't > > all "compatible" mainly because of javascript namespacing issues, and > > making people download multiple libraries is kind of a bad idea > > anyway. > > Yes, that is why a preferred simple js library should be picked for > use case 1. I thought mochikit is a good choice but if more people > prefer jquery that's fine too. The point is that there should be a > preferred choice made by the developers so we -- the users -- don't > have to think about it. > > > So we need to choose 1 that we use in the basic widgets. As I see it > > the candidates are mochikit, jquerry, ext.js and perhaps dojo and > > yahooui. jquerry is the smallest and tightest, ext.js is the richest > > and most complete, but it;s very large. It seems that most of case 1 > > is covered quite well by jquerry, but use case 2 is not covered at > > all. > > Indeed, jquery looks like a good choice for use case 1. > > > ext.js covers use case 2 well, but adds considerable download and > > parse time overhead to those who are part of use case 1. > > Yes, so the dependency on ext.js should only be in complicated > widgets, but ext.js should be the only dependency and not other js > libraries. This of course leaves open the door for anyone writing > widgets for tg using other js libraries but the widgets that form the > core of tg (or TW) should all use ext.js (or the rich client UI js > library that developers choose, I personally think ext.js is the best > choice). > > > One solution is to use ext.js and jquerry together as this is an > > explicitly supported configuration of ext.js. However, this adds > > some documentation overhead to those working in use case 2 with > > widgets. But since most widgets can just depend on jquerry, and my > > experience is that most people building rich web applications are > > going to be writing lots of javascript by hand, I think it's > > reasonable to standardize on jquerry and include ext.js where > > nessisary in a way that is known to work fine. > > Yes, most widgets can just depend on jquery but as soon as you do > something more complicated you'll end up duplicating stuff already > existing in ext.js or another rich library. So again I agree, simple > widgets should be standardized on jquery while complicated widgets on > ext.js. > > > In particular this is a question that I think Alberto/ToscaWidgets is > > going to be handling. > > > > What do you all think? > > > > > > > > > >> Good point. I think it's about which library should be preferred to > > > > >> built the more advanced widgets with, like AjaxGrid or > > AutoCompleteField. > > > > > > > > > > But won't these be available through TW only? I thought we were > > moving > > > > > widgets code out of TG2 and into TW. > > > > > > > > I must admit that I haven't played with TW yet. It seems the base TW > > > > widgets don't need any JS library, but there are widgets to support > > > > mochikit and jQuery, is that right? > > > > > > > > > I agree with many of the commenters that tg is about making good > > > choices by tg developers for app developers but not forcing any choice > > > too much. Mochikit is great and should be used in simple tasks so > > > probably it should stay in a vanilla tg install. > > > > > > Now if all widget specific things are moving to TW and will completely > > > decouple from tg then probably what I'm advocating is the development > > > of a subset of TW that does nothing else then wrapping ext.js widgets. > > > And this subset of TW should be clearly visible and should be the > > > "blessed" choice so that users will have something to go with > > > immediately. > > > > > > I'm speaking here from my own experience. I've spent weeks and weeks > > > reviewing and evaluating JS libraries for rich client user interfaces > > > (something mochikit is *not* good for) but on the other hand I did not > > > spend any time reviewing and evaluating development web servers, > > > templating systems and such because the tg developers already made > > > these choices for me (cherrypy, kid) which is really a great thing. > > > > > > I guess by separating the use cases to (1) mostly non-visual ajax > > > stuff (2) really rich client UI, it is fair to say that mochikit is > > > great for (1) but not so for (2). The introduction of a "blessed" JS > > > library with appropriately wrapped widgets would cater for (2). > > > > -- 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" 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?hl=en -~----------~----~----~----~------~----~------~--~---
