JavaScript and Changeset 3541
John Sutherland
I don't want sound like an arse, but has anyone seen changeset 3541 [1]?
I understand it's still a branch [2], but are we going to be getting
all that YahooUI stuff in trunk?
I don't want to get in a flame-war about the whole AJAX/JavaScript
thing, but I'm of the impression that Django is for the server-side
stuff, if I wanted to do cool-guy AJAX stuff I'd choose a JS framework
and get own with writing the missing bits myself.
Cheers, John.
[1] <http://code.djangoproject.com/changeset/3541>
[2] <http://code.djangoproject.com/browser/django/branches/per-object-permissions>
Malcolm Tredinnick
On Wed, 2006-08-09 at 10:41 +0100, John Sutherland wrote:
> Hi all,
>
> I don't want sound like an arse, but has anyone seen changeset 3541 [1]?
>
> I understand it's still a branch [2], but are we going to be getting
> all that YahooUI stuff in trunk?
>
> I don't want to get in a flame-war about the whole AJAX/JavaScript
> thing, but I'm of the impression that Django is for the server-side
> stuff, if I wanted to do cool-guy AJAX stuff I'd choose a JS framework
> and get own with writing the missing bits myself.
> [1] <http://code.djangoproject.com/changeset/3541>
> [2] <http://code.djangoproject.com/browser/django/branches/per-object-permissions>
I saw it go past, but was personally not too worried about it at the
moment for a few reasons (really personal opinion only, read nothing
more into this): It's a Summer of Code project, so there's no policy
setting or anything going on there. Presumably (hopefully!) the
per-object functionality is not dependent upon that particular admin
interface implementation, so when we evaluate the results at the end of
the project, we should be able to separate out the various pieces and we
can decide then whether or not the admin implementation is something we
want to adopt. Setting up a working implementation of "here's how the
admin interface could work for this" is not a crazy idea, though.
It's a sandbox for Chris Long's "in development" work. I'm inclined not
to worry about in progress stuff too much just yet.
Regards,
Malcolm
Chris Long
I'm the developer working on the branch.
A few things, hopefully to answer your concerns.
1) The HTML and JS is written that the AJAX can be turned off very
easily(currently it works better with JS disabled then enabled). And I
plan on implementing a method of selecting if you wish to use the AJAX
or not. I might even implement it so you have to install the YUI
toolkit seperately rather then increse Django's size (though w/ the YUI
toolkit it works out to about 50-75kb increase in size).
2) The current way I have the interface set up, I find it improves the
interface greatly to have AJAX send the request to the server and
update the page. I plan on adding some "Apply selected" and "Delete
selected" buttons in the next few days but the AJAX does help.
3) The Admin interface already uses a lot of javascript code, I'm just
the first to use a toolkit rather then bits and pieces.
Hopefully that answers some of your concerns. I'm curious as to the
communities take on it, if in general the opinion is to remove it then
I will. I personally think the admin interface would work well with
some AJAX built into it, but I know that isn't the case with everyone.
Comments? Concerns?
Chris
Ian Holsman
John Sutherland
Thanks for your responses - concerns have been relieved.
I wasn't aware that there was no obligation to include the SoC stuff.
I think that the admin would gain a lot from having more JS/AJAX stuff
and that it would be a wise decision to pick a framework and run with
it. However as soon a a JS framework is bundled with Django it will
start to influence the rest of the project.
I'd rather have bits and pieces of JS in the admin than a framework if
only to halt influence on the developers and us ending up knee deep in
a JS framework like Rails (recognising though that Prototype was
developed as part of Rails).
Cheers, John.
PS. I am totally looking forward to the per-object permissions stuff,
so keep up the good work :D
Adrian Holovaty
> Hopefully that answers some of your concerns. I'm curious as to the
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?
I have not looked at this branch at all, but I'll strongly suggest
that you remove the YUI stuff.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Linicks
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?
>
> Chris
AJAX integration is a nice touch, but I think that the use of YUI goes
against the established use of Dojo with Django. After reading the
proceeding threads in this post, a couple of questions come to mind:
1. Chris, would it be reasonable to move your work to Dojo?
2. Project leaders, if Chris were to move his Ajax work to Dojo,
would it be well received?
--Nick
Malcolm Tredinnick
[...]
> AJAX integration is a nice touch, but I think that the use of YUI goes
> against the established use of Dojo with Django.
Where are we using Dojo at the moment?
Malcolm
Eugene Lazutkin
>
> AJAX integration is a nice touch, but I think that the use of YUI goes
> against the established use of Dojo with Django. After reading the
> proceeding threads in this post, a couple of questions come to mind:
>
> 1. Chris, would it be reasonable to move your work to Dojo?
>
> 2. Project leaders, if Chris were to move his Ajax work to Dojo,
> would it be well received?
I am not sure if it is reasonable to use Ajax for "per object
permissions". But if the decision is made, I can help to move it to
Dojo. In any case putting any 3rd-party JS library code in Django's
repository doesn't feel right for me --- we are not going to maintain it
anyway.
Thanks,
Eugene
James Bennett
> 1. Chris, would it be reasonable to move your work to Dojo?
From the looks of things, that's how he'd implemented it at first; he
then switched to YUI.
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
James Bennett
> communities take on it, if in general the opinion is to remove it then
> I will. I personally think the admin interface would work well with
> some AJAX built into it, but I know that isn't the case with everyone.
> Comments? Concerns?
I like the idea of adding AJAX-powered enhancements to the admin
application, but I really think that's something to deal with
separately; perhaps one of these days we should get an "admin-ajax"
branch going, and attack the problem that way.
Ian Holsman
On 8/9/06, Chris Long <indir...@gmail.com> wrote:Hopefully that answers some of your concerns. I'm curious as to thecommunities take on it, if in general the opinion is to remove it thenI will. I personally think the admin interface would work well withsome AJAX built into it, but I know that isn't the case with everyone.Comments? Concerns?I have not looked at this branch at all, but I'll strongly suggestthat you remove the YUI stuff.
Adrian--Adrian Holovaty
Linicks
Malcolm,
I'm not sure how much it's being used in the current trunk, however
it has been discussed many times. Here are a few links that may
interest you.
- http://blog.dojotoolkit.org/2006/02/01/dojo-django
- http://lazutkin.com/blog/2006/jan/28/django-dojo/
- http://article.gmane.org/gmane.comp.web.dojo.user/3603
-
http://spoken.phrasewise.com/articles/2006/02/01/django-adopts-dojo-as-ajax-framework
- http://groups.google.com/groups/search?q=django+dojo+integration&
--Nick
Eugene Lazutkin
> On 8/9/06, Linicks <lin...@gmail.com> wrote:
>> 1. Chris, would it be reasonable to move your work to Dojo?
>
> From the looks of things, that's how he'd implemented it at first; he
> then switched to YUI.
Do you know the reason? I am curious to know what was wrong.
Thanks,
Eugene
Chris Long
wanted to try a few different toolkits to practice with them and find
out the differences. I have never touched AJAX before this summer.
I tried Dojo first and did like it, and wrote some working code, which
I should be able to rewrite to be more efficient (or the other option I
stated below). When I started with YUI I had a much better
understanding of what I wanted to do and AJAX/Javascript itself, so I
found the code I wrote with YUI working a bit better.
The work can be moved to Dojo fairly easily, as it mostly is rewriting
the actual AJAX communication, the animations (which can easily be
removed, mostly there from me practicing with them, and the DOM
commands). The remaining JS is outputting the return message, creating
a new row, etc. which is non-toolkit specific.
If the opinion is to remove the AJAX code totally, I can do this in
such a way that it can be easily reinserted at such a point where we
want to implement AJAX into the admin interface. For now, I'll separate
the AJAX JS and the non-AJAX js and it can be decided what remains and
what goes.
Cheers,
Chris
Max Derkachev
> that you remove the YUI stuff.
Adrian, could You explain your opinion a bit more?
Does that mean that there are plans to bundle another toolkit? If yes,
what toolkit?
Regards,
Max
Max Derkachev
Hopefully, there would be no such "established uses" with any JS
library. Django is a server-side framework. Even id Django is our
framework of choice, let us decide which client-side framework to use
in our applications.
Regards,
Max.
Joe
This is true, but we could consider making Django 'plug and play' with
a few of the more popular frameworks.
Adrian Holovaty
Hey Max,
Sure, I'd be happy to explain -- my (very strong) preference is to
bundle *no* JavaScript toolkit. That's partially because we shouldn't
limit which toolkit developers use, and partially because it's
unnecessary bloat within the Django distribution.
Jeremy Dunck
> Sure, I'd be happy to explain -- my (very strong) preference is to
> bundle *no* JavaScript toolkit. That's partially because we shouldn't
> limit which toolkit developers use, and partially because it's
> unnecessary bloat within the Django distribution.
What about something like django.contrib.client?
This leads me to wonder whether there should be release flavors (a la
slackware vs. ubuntu) down the road.
Max Derkachev
Thanks for explanation.
I am also against bundling any JS toolkit with *core* framework.
--
Regards,
Max
simonbun
framework.
Last time i checked, there's about 65Kb of custom JS in django already.
>From a first glance this is all functionality that can be found in most
JS toolkits. Right now, if i want to use a toolkit, i have to accept
its footprint plus that of django's custom JS. If a modular js toolkit
is chosen, or a toolkit that is willing to have a custom branch for
django developers, i bet we could go below that 65Kb and have more
functionality to boot.
The positive side to bundling a JS toolkit:
- No need to maintain/extend the JS code yourselves
- There'd be clarity for the developer that wants to use A toolkit.
Some people are not in a specific JS toolkit camp, and don't mind
learning one, but right now are unsure as to wich one to pick.
- Ajax would be a possibility. I know many of you don't like ajax, but
i believe that if its used with consideration and restraint (i.e. no
color-changing div layers flying about), it can be a big plus. This
does not mean that the admin generator should use ajax per default
though.
The negative side:
- Some people will rather use another JS toolkit than the one that will
be chosen (and will rant about it). On that note, i don't think it
would be too hard for someone to write a wiki entry on how to replace
default toolkit X with their toolkit Y (and explain its superiority).
Some notes on implementation:
- I suggest a thread is started where the pros & cons of all JS
toolkits are weighed in, and a choise is made as a community on wich
one to pick. 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.
- 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.
Feel free to disagree with me, but voice your opinion please.
Simon.
Malcolm Tredinnick
> 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.
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.
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 ....?
> - 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.
> 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.
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
Deryck Hodge
> - Ajax would be a possibility. I know many of you don't like ajax, but
> i believe that if its used with consideration and restraint (i.e. no
> color-changing div layers flying about), it can be a big plus. This
> does not mean that the admin generator should use ajax per default
> though.
The above point is inaccurate, assuming you based your opinion on the
fact that core developers don't support bundling a JS toolkit with
Django. Adrian's own chicagocrime.org is AJAX/JavaScript heavy, using
Google Maps. James has written articles on his site about developing
AJAX apps with Django. These are just a couple examples. The wiki is
full of more.
We use JavaScript quite heavily at Naples News and the other sites we
manage for NDN. I know other Scripps sites use a fair amount of
JavaScript, whether its really AJAX or not I can't say. There are
others here who could speak to their own use and appreciation of
JavaScript and AJAX. So I don't think its fair to say "many of you
don't like ajax" just because Django doesn't ship with a JS toolkit.
Cheers,
deryck
--
Deryck Hodge http://www.devurandom.org/
Web Developer, Naples News http://www.naplesnews.com/
Samba Team http://www.samba.org/
simonbun
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.
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
James Bennett
> 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.
I submitted a partial porting of the admin JS to the Dojo toolkit a
while back, but honestly I don't mind one way or the other if it ever
goes in. If we decide to do real AJAX stuff in the admin app, then
we'll probably have to pick a toolkit for it and bundle that with the
admin app. For now, "waste" strikes me as a non-issue -- it's like
saying that because the admin app uses XHTML 1.0 Strict, it'd be
"wasteful" for someone to have their public-facing templates be HTML
4.01 Transitional. What the admin app does or doesn't do shouldn't
have any bearing on the techniques you choose for the public part of
an application.
> 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.
The problem here is that, well, there's no such thing as "swimming in
the same direction" -- to get that to work, there would have to be a
one-size-fits-all JS toolkit out there, and there just isn't and never
will be such a thing.
But if somebody wants a "blessing", then here's a blessing that
carries whatever weight people attach to my rambling opinions:
The official JavaScript toolkit of the Django web framework is the one
that best suits what you want to do with it.
The BDFL bless you and keep you, etc.
> 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.
Time and time and time again we've seen people who -- literally --
would take a "bundled" toolkit as a blanket statement of "use this,
and nothing else". That's not how we roll.
And the opposite statement could be made in response to your argument
-- *not* choosing a particular toolkit doesn't get in anyone's way,
either.
Bill de hÓra
> 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.
+1. Bundling a toolkit is checkboxing, frankly.
"I'm not so sure its such a bad idea to bundle a JS toolkit with the
framework."
I read that as "an AJAX toolkit would be nice to have".
cheers
Bill