Malcolm Tredinnick wrote: > On Sat, 2006-08-19 at 07:57 +0000, simonbun wrote: > > I'm not so sure its such a bad idea to bundle a JS toolkit with the > > framework. > > It's only been a month since the last time we had this thread. Do we > have to do this again? :-( > > Really, you bring up nothing that hasn't been covered in the Lord knows > how many threads on this we've had over the last eight to 12 months. > > Lack of a "blessed" or include Javascript toolkit does not prevent > anybody from writing Ajax applications. It does not prevent anybody from > doing anything they could do if we had a library included, outside of > the maybe four people who work on the Admin interface. > > You claim that including a toolkit will "make Ajax a possibility", but > since it's already a possibility (people are already building > Ajax-enabled Django-backed websites), it's not clear what you mean. >
Maybe it was better to dig up an old thread. I just read some arguments against using a toolkit in this thread that i didn't agree with. I'm well aware that its no problem to use ajax right now by using any JS toolkit. My point was that it seems somewhat wasteful to have custom JS scripts for the admin generator, and then using a JS toolkit that does the same thing. > The "if we don't have one people won't know what to choose" argument > seems weak. It's "please help save me from having to think for myself." > Django is NOT a Javascript-based framework, so us suggesting a > Javascript toolkit is just another voice in the crowd with no more > credibility than the next guy. Thats not the issue. Everyone can make their own choise perfectly well, but if a "blessed" toolkit is chosen, more people are swimming in the same direction. Wich would make it easier to bounce off of each others' ideas & code, and maybe to help others that are stuck on something. To me thats a benefit, to others maybe a limitation. > > There are probably some advantages to doing some Admin stuff with Ajax. > But that's just the admin interface. Somebody wanting to prove their > point should feel free to write an application that shows all this > wonder. Remember, there is nothing to prevent having an external admin > app. It's just an application, after all; you don't need to ship a patch > that changes the core distribution. I more than suspect that will happen > one day. > > [...] > > - I suggest a thread is started where the pros & cons of all JS > > toolkits are weighed in, > > Please, no! > > This has been done on the Django lists before. Just search the archives. > More importantly, it's been done in Javascript forums before as well. > Consensus is that all the popular ones are sufficiently good and fit for > purpose. Opinions vary about absolute best, but that's life in the > software industry, since it's unlikely there is any way to measure > "absolute" best in an objective fashion. > > > and a choise is made as a community on wich > > one to pick. > > We seem to have already made a choice. You would like a different > choice. At which point will this argument stop going around and around? > > Feel free to recommend your favourite toolkit at every possibility. > Point people towards articles showing how to integrate it. You will get > lots of thanks from the people asking the questions and no complaints > from anybody else (other than those still working on the support > materials for their own favourite toolkit). You can even host these on > the Django website. It's why we have the Wiki. Guys like Dave Coulix > have already posted some Ajax + Django articles. > > > Frankly, i don't think many will get religeous about their > > toolkit. I believe most (including me) just want A toolkit. > > > - I think the chosen JS toolkit should be as loosly coupled with the > > framework as possible. i.e. no javascript helpers (à la RoR) that > > sprout blocks of javascript code everywhere. > > No helpers seems to imply there's no particular way to use the toolkit > we include beyond standard "write your own" accessors. The benefit to > including it would then be ....? I don't think its right to bloat the core with javascript helpers. I never liked the whole idea of helpers and i believe every developer should know how to write the necessary javascript "manually". The benefit, like i said earlier, is to avoid JS code redundancy. And to offer a lot more possibilities than there are at the moment. > > > - If implemented correctly, i don't see how choosing a JS toolkit would > > get in the way of anyone, even people that don't want to use JS or ajax > > or whatever at all. > > This kind of lack of specificity doesn't help your arguments at all. > It's a self-fulfilling statement: if the toolkit integration does get in > the way, then it's not implemented correctly. > How is that a self-fulfilling prophecy? I was just saying that choosing a particular toolkit will not get in the way of django developers that choose not to use it. Much like the current JS doesn't get in the way. > > Feel free to disagree with me, but voice your opinion please. > > This list is busy enough without having the same threads over and over > again. This one has long passed the point where abstract discussion is > useful. If somebody is convinced that their idea is absolutely vital, > it's time to show us the code. > > Your email does not describe any benefits outside of a possible, > unmeasured decrease in the Admin javascript size (and less code does not > mean easier maintainability, by the way) that are not already present. > It seems premised on the "people don't know what to choose" point a lot. > Those people should choose Dojo. No reason other than it means they no > longer have to live in uncertainty. Well i'm not going to rewrite the admin backend with a toolkit just to prove a point, it was an educated guess. I will use whatever i need in my own apps, i'm just trying to ... help i guess. Part of the strength of an open sourced project is its community, but everybody can make his own personal version of django ofcourse. Thanks, Simon > > It's certain that one day we will have Admin-next-gen, but it will > equally certainly live as a parallel application for a while first and > nobody's written it yet (well, James B wrote one patch, but it doesn't > seem to have set the world on fire). And nowhere else is Javascript used > in Django's main distribution. > > Regards, > Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
