Small report from Django/Rails meetup

[Robert Wittams]

So I went to the London Django/Rails meetup yesterday. In general a good
time was had - met Simon Willison, and some ThoughtWorks guys doing a
GreenPeace site with Django.

The general feeling from those using or considering Django (including
some rubyists) seemed to be "Release a 0.7 tarball, for the love of all
that is holy!"

It seems that quite some people just aren't comfortable with checking
things out of subversion. They don't particularly want backwards
compatibility, just a tarball. This would probably widen the number of
people willing to use/try out Django.

There seems to be some plan of releasing 1.0 in the near future. I'm not
convinced that is a great idea if backwards compatibility needs to be
preserved after this, as there are still a number of fairly major things
that do need work and thought, as well as practical experience.( eg
authorisation, schema transitions, etc). I personally do not know of any
pressing need to release a 1.0 .

It doesn't seem that being pre-1.0 has had a significant negative impact
on the hype surrounding certain other projects - but having no releases
does seem to be having some negative effect, however small, on us.

Any thoughts?

[Adrian Holovaty]

On 11/8/05, Robert Wittams <rob...@wittams.com> wrote:
> The general feeling from those using or considering Django (including
> some rubyists) seemed to be "Release a 0.7 tarball, for the love of all
> that is holy!"
>
> It seems that quite some people just aren't comfortable with checking
> things out of subversion. They don't particularly want backwards
> compatibility, just a tarball. This would probably widen the number of
> people willing to use/try out Django.

If all this means is automatically packaging a tarball every couple of
days/weeks, let's do it.

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org

[Jacob Kaplan-Moss]

On Nov 8, 2005, at 10:13 AM, Adrian Holovaty wrote:
> On 11/8/05, Robert Wittams <rob...@wittams.com> wrote:
>> The general feeling from those using or considering Django (including
>> some rubyists) seemed to be "Release a 0.7 tarball, for the love
>> of all
>> that is holy!"
>>
>> It seems that quite some people just aren't comfortable with checking
>> things out of subversion. They don't particularly want backwards
>> compatibility, just a tarball. This would probably widen the
>> number of
>> people willing to use/try out Django.
>>
>
> If all this means is automatically packaging a tarball every couple of
> days/weeks, let's do it.

I think we need to bite our lips, suck it up, and release a 1.0
version. It seems that we keep running into feeping-creaturism every
time we try to set a stake in the ground, and that's limiting
adoption. Obviously everyone is unhappy when their tickets aren't
included, but more tickets are being opened than fixed. I think we
need to accept that certain things might not get done, release a 1.0,
and move on.

[Calling it "0.7" would inaccurately represent how stable and usable
Django is, which is why I say 1.0.]

If it sounds OK, I'd like to start a 1.0 release branch and only
apply any outstanding bug fixes to it; moving feature requests/
patches to a 1.1 target. That way we can get a stable 1.0 out the
door and focus on 1.1 for feature improvements.

In terms of backwards-compatibility, it seems most of the big deal
architectural changes have already been done, and as long as we
provide VERY EASY upgrade paths from 1.0 -> 1.x I think we're OK.

So, any objections to starting a 1.0 bug-fix-only release branch?

Jacob

[Eric Walstad]

On Tuesday 08 November 2005 08:35, Jacob Kaplan-Moss wrote:
> I think we need to bite our lips, suck it up, and release a 1.0  
> version.

+1

A "stable" release would make those who are trusting my judgement in
choosing Django for a medium-large-ish project a little less nervous
(me, too).

[Adrian Holovaty]

On 11/8/05, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
> If it sounds OK, I'd like to start a 1.0 release branch and only
> apply any outstanding bug fixes to it; moving feature requests/
> patches to a 1.1 target. That way we can get a stable 1.0 out the
> door and focus on 1.1 for feature improvements.
>
> In terms of backwards-compatibility, it seems most of the big deal
> architectural changes have already been done, and as long as we
> provide VERY EASY upgrade paths from 1.0 -> 1.x I think we're OK.

Here's what we should finish before this first 1.0 version:

* Transactions.
* New-admin branch.
* Reworking of the RSS framework (I believe there's already a patch,
which I can roll in).
* Documentation.
* Screencasts so fucking exciting you'll cry.

[Jakub Labath]

Eric has a point.
It would help to have a stable release as a selling point to my
customers/managers. Even in the case when I would in fact use the code
in svn for the actual work.:-)
Unfortunately world is all about perceptions.

[espen.g...@gmail.com]

I got to say that I really think what adrian says is the right thing to
do. Get the docs done, and merge the new-admin got to be top priority
in my opinion.

[Jacob Kaplan-Moss]

On Nov 8, 2005, at 11:08 AM, Adrian Holovaty wrote:
> Here's what we should finish before this first 1.0 version:
>
> * Transactions.

Agreed.

> * New-admin branch.

What's the state of this branch? Last time I tried it out -- a few
weeks ago, IIRC -- there seemed to be a bunch more work to be done.
I'd obviously LOVE to see this get rolled in, but if it's a "few
months" thing I don't think it would hurt to let it hit in 1.1.

> * Reworking of the RSS framework (I believe there's already a patch,
> which I can roll in).

Agreed.

> * Documentation.

What do you think we ought to document? RSS and the comments
framework come to my mind; anything else? We should come up with a
list and work out who will write what.

> * Screencasts so fucking exciting you'll cry.

(Sounds like something Rob would say <grin>)

These might be more difficult as they should ideally be taken *of*
1.0 (not before), so they might need to be something we do after 1.0
is done. Perhaps the best approach would be to make these when we
hit a 1.0 release candidate (after all the above is done).

To this list, I would add two things:

* A solution to the "OR" dilemma; #251 seems like an OK fix to me.
* Solidifying the middleware API and the "stacking" issue (I've got a
draft proposal of this including an explanation of why I did it the
way I did; I'll try to wrap it up and post it soon).

Jacob

[Adrian Holovaty]

On 11/8/05, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

> What's the state of this branch? Last time I tried it out -- a few
> weeks ago, IIRC -- there seemed to be a bunch more work to be done.
> I'd obviously LOVE to see this get rolled in, but if it's a "few
> months" thing I don't think it would hurt to let it hit in 1.1.

I'd like to see a solution to "core=True" before 1.0 -- i.e., not
having to use that anymore. This goes beyond what new-admin offers,
and it would probably be a backwards-incompatible change (hence the
1.0 requirement).

> What do you think we ought to document? RSS and the comments
> framework come to my mind; anything else? We should come up with a
> list and work out who will write what.

* RSS
* Comments framework
* Authentication (already started; I need to finish)
* Admin-site documentation (already started on my laptop; I need to finish)
* Views (already started on my laptop; I need to finish)
* Finish tutorial
* How to contribute to Django, and how development works
* How to integrate third-party template systems

I'd prefer to do all of these myself, with the exception of the last two.

> These might be more difficult as they should ideally be taken *of*
> 1.0 (not before), so they might need to be something we do after 1.0
> is done. Perhaps the best approach would be to make these when we
> hit a 1.0 release candidate (after all the above is done).

Good call.

> * A solution to the "OR" dilemma; #251 seems like an OK fix to me.

Yes, we should fix this one. #251 still rubbed me the wrong way last
time I checked, but I'll give it some more thought.

> * Solidifying the middleware API and the "stacking" issue (I've got a
> draft proposal of this including an explanation of why I did it the
> way I did; I'll try to wrap it up and post it soon).

Looking forward to it...

[Pedro Furtado]

2005/11/8, Adrian Holovaty <holo...@gmail.com>:

>
> * RSS
> * Comments framework
> * Authentication (already started; I need to finish)
> * Admin-site documentation (already started on my laptop; I need to finish)
> * Views (already started on my laptop; I need to finish)
> * Finish tutorial
> * How to contribute to Django, and how development works
> * How to integrate third-party template systems

Why don`t we include Django-Ajax in 1.0? I agree that releasing it
sooner is good for the project but a nice ajax interface is the future
for all web applications. Don`t you agree this is an imprescindible
update?

[Jonathan Daugherty]

# Why don`t we include Django-Ajax in 1.0? I agree that releasing it

# sooner is good for the project but a nice ajax interface is the
# future for all web applications. Don`t you agree this is an
# imprescindible update?

I think that really goes into the "bells and whistles" category.
Admittedly, AJAX integration of some kind would be nice, but IMHO
there are lots of other bigger, more important things going on that
need to be considered.

--
Jonathan Daugherty
http://www.parsed.org

[Jeremy Dunck]

On 11/8/05, Adrian Holovaty <holo...@gmail.com> wrote:
> * Screencasts so fucking exciting you'll cry.

I'll stock up on gatorade.

[Jeremy Dunck]

On 11/8/05, Pedro Furtado <pedrol...@gmail.com> wrote:
> Don`t you agree this is an imprescindible
> update?

I dunno what imprescindible means. :)

[Maniac]

Jacob Kaplan-Moss wrote:

> So, any objections to starting a 1.0 bug-fix-only release branch?

No objection but a concern...

Some time ago I filed a ticket
(http://code.djangoproject.com/ticket/570/) about FormWrapper not
working for ForeignKey fields. It's rather basic functionality and I
consider it a major disfunction to be fixed for 1.0. But the ticket was
duplicated against 'new-admin' branch which fixes this bug.

Now I'm afraid that the whole 'new-admin' could be considered a large
dangerous feature for 1.0 and thus left out. If so then we should
extract any critical fixes (such as 570) from it and apply them to the
1.0 branch.

[Jacob Kaplan-Moss]

On Nov 8, 2005, at 11:30 AM, Adrian Holovaty wrote:
> I'd like to see a solution to "core=True" before 1.0 -- i.e., not
> having to use that anymore. This goes beyond what new-admin offers,
> and it would probably be a backwards-incompatible change (hence the
> 1.0 requirement).

That's a good point -- core=True sucks (just got bit by it again
today: don't make a radio button field to core or else once you've
set it you can never erase the row *sigh*).

Robert, is this something you were planning on including the new-
admin, or is it something that would need to be done once those
changes hit the trunk?

> * How to contribute to Django, and how development works
> * How to integrate third-party template systems
>
> I'd prefer to do all of these myself, with the exception of the
> last two.

I'll happily write those; I've got strong opinions about both of them :)

> Yes, we should fix this one. #251 still rubbed me the wrong way last
> time I checked, but I'll give it some more thought.

I also don't like #251 that much, but I'd take it over the scary
undocumented "_or" we've got now (and over raw SQL, which sucks).

Jacob

[Eugene Lazutkin]

Inline.

"Adrian Holovaty" <holo...@gmail.com> wrote
in message
news:6464bab0511080908p306...@mail.gmail.com...

On 11/8/05, Jacob Kaplan-Moss
<ja...@jacobian.org> wrote:

> * Transactions.

There are problems with transactions in caching --- sometimes database is
locked up for no reason without any errors. I didn't have time to look at it
but I am getting some bad side effects time to time. Of course, transaction
for data updates would be nice to have as well.

> * Screencasts so fucking exciting you'll cry.

+10! That is how it works nowadays. I don't know why they are so popular. I
gave up explaining this phenomenon. But confronted with data from my web
site I just admit that it is a fact of life.

Additional wish: multithreaded MySQL support. Unfortunately MySQL is much
more popular with hosting companies than Postgres. There is a patch for
MySQL. I use it for a long time without problems.

Thanks,

Eugene

[Ian Holsman]

personally I'd like to see the user-registration app get
documented/released as well.
what is the state of this?

--
I...@Holsman.net -- ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti

[Jacob Kaplan-Moss]

On Nov 8, 2005, at 2:33 PM, Ian Holsman wrote:
> personally I'd like to see the user-registration app get
> documented/released as well.
> what is the state of this?

The registration app (as opposed to just the user module) is
currently part of our proprietary software package and I'm not sure
it's something we want to release; I'll talk it over with some people
internally and look into releasing it as django.contrib.registration.

Jacob

[Robert Wittams]

Ok, so this generated quite a bit of traffic.

I *really* don't think that 1.0 should be considered on the basis of
stability and usability of the implementation. It should be on the basis
of "is this a reasonable base to offer backwards compatibility for", ie
how much do we *know* is going to have to change.

These are the things that definitely need to happen before we end up
with a commitment to back compat nightmares:

1) Get rid of core fields * ( this blocks a surprising amount of stuff).
2) Sort out whether magic model modules are really a good idea. Adrian
was talking about this, I also talked to Simon about this yesterday at
the meetup. I am in favour of getting rid of them.
3) Some kind of story on authorisation that works for people other than
newspapers, and isn't an enforced ACL mire. *
4) Transactions
5) Real subtyping as discussed a few weeks ago *
6) Proper schema checkpointing and transitioning *
7) Extract the admin history thing from manipulators into a seperate app*

I was planning to do the * items in a branch before 1.0, with the
explicit aim of doing every breaking change in one lump before 1.0 so as
to minimise the number of times people have to mess with their models.

The reason I haven't done any of these yet is because new-admin is
supposed to be backwards compatible model wise. I could change this, but
it makes checking for regressions much harder.

I have no idea why we have to marry the idea of releasing a tarball to
the number 1.0, but the number 1.0 is already explicitly married to
backwards compatibility in the eyes of most users. IMO there are still a
number of areas that need a fair amount of work.

I would be much happier just releasing a tarball with no guarantees. I'd
even be happier about releasing nothing than rushing 1.0. This is
exactly the scenario I'd hoped to avoid with my message, emphasising
that right now, people seem far more concerned about just having a
tarball out there than they do about version numbers or backwards
compatibility.

So when we say "release a 1.0, and move on.", we are IMO making an
explicit back compat commitment, and so moving on is just what we will
be precluding.

------------------
As to the state of new-admin at the moment, it is fairly complete
functionality wise, and stability wise I do not believe it is
significantly worse than trunk. I do still have a very small number of
bits to templatise - date_hierarchy in the change_lists being the main
offender.

I'm still not satisfied with the api of auto generated forms - there is
some duplication between formfieldwrappers and the tower of bound
classes. I think that I will leave this to stew for a while, and fix it
properly in the backwards incompatible branch - I have a feeling the
clean solution to this may rely on getting rid of core fields. This is
why I have not documented it at all in NewAdminChanges.

[hugo]

>I also don't like #251 that much, but I'd take it over the >scary
>undocumented "_or" we've got now (and over raw SQL, >which sucks).

How about another solution to expression combination: wrapping query
expressions (the field__exact and friends) optionally in Query()
objects that implement __or__ and __and__ - that way you can do
Query(field__exact=blah)||Query(field__exact=blubb).

I did something like this for my active storage framework (a rather
weird database thingy - don't ask) and it worked quite nice. You would
need to extend the get_list() and friends to check for a parameter that
isinstance(Query) and than "compile" the query expression to SQL.

bye, Georg

[hugo]

>I have no idea why we have to marry the idea of releasing a tarball to
>the number 1.0, but the number 1.0 is already explicitly married to
>backwards compatibility in the eyes of most users. IMO there are still a
>number of areas that need a fair amount of work.

I would say: release a 0.9 version now (or in the near future) and give
a clear roadmap (that's what the trac feature is for ;-) ) of what will
go into 1.0 before release. That way people have some "quite stable
but not 1.0" tarball to play with, with a defined
compatibility-breakage ahead, but one they are warned about. That would
give us a bit more time to do the 1.0 right.

bye, Georg

[Adrian Holovaty]

On 11/9/05, hugo <g...@hugo.westfalen.de> wrote:
> I would say: release a 0.9 version now (or in the near future) and give
> a clear roadmap (that's what the trac feature is for ;-) ) of what will
> go into 1.0 before release. That way people have some "quite stable
> but not 1.0" tarball to play with, with a defined
> compatibility-breakage ahead, but one they are warned about. That would
> give us a bit more time to do the 1.0 right.

This sounds great to me. Thoughts, Jacob and everybody else?

[Jeremy Dunck]

On 11/9/05, Adrian Holovaty <holo...@gmail.com> wrote:
>
> On 11/9/05, hugo <g...@hugo.westfalen.de> wrote:
> > I would say: release a 0.9 version now (or in the near future) and give
> > a clear roadmap (that's what the trac feature is for ;-) ) of what will
> > go into 1.0 before release. That way people have some "quite stable
> > but not 1.0" tarball to play with, with a defined
> > compatibility-breakage ahead, but one they are warned about. That would
> > give us a bit more time to do the 1.0 right.
>
> This sounds great to me. Thoughts, Jacob and everybody else?

This sounds something like what Robert originally suggested, with the
version number changed. Which is to say, +1. :)

[Jacob Kaplan-Moss]

On Nov 8, 2005, at 3:41 PM, Robert Wittams wrote:

> Ok, so this generated quite a bit of traffic.
>

Ha -- thanks for kicking this off; it needed to be discussed.

> I *really* don't think that 1.0 should be considered on the basis of
> stability and usability of the implementation. It should be on the
> basis
> of "is this a reasonable base to offer backwards compatibility
> for", ie
> how much do we *know* is going to have to change.
>

I agree that this is a noble goal, and in a perfect world Django 1.X
would be completely compatible with Django 1.Y. However, the reason
I'm wanted to push out something called "1.0" is that Django's
*perceived* instability is hampering its adoption. The fact is that
people read "0.7" as "zero-point-missing-many-features" and shy
away. With enough eyeballs all bugs are shallow, and I want more
eyeballs (mmmm.... eyeballs....)

> These are the things that definitely need to happen before we end up
> with a commitment to back compat nightmares:
>
> 1) Get rid of core fields * ( this blocks a surprising amount of
> stuff).
>

Agreed (as I've said before).

> 2) Sort out whether magic model modules are really a good idea. Adrian
> was talking about this, I also talked to Simon about this yesterday at
> the meetup. I am in favour of getting rid of them.
>

Let's bring this up on a different thread since it's a big issue; my
10-second response is that this would take a *lot* of time, and
aren't there more important things to be doing?

> 3) Some kind of story on authorisation that works for people other
> than
> newspapers, and isn't an enforced ACL mire. *
>

This is a HUGE task; I think you know that. Coming up with a auth
system that doesn't get in the way of most people but has all the
power you could ask of it certainly is going to be difficult, and
finding consensus among developers on how auth "should" work could
easily turn into a holy war (the last time we discussed the topic the
tone turned nasty fairly quickly). Frankly, I'd guess that for over
90% of Django's users the current simple auth system is *too*
complicated for their needs. This isn't to say that I wouldn't LOVE
to see this happen, but simply that it, too, is a lot of work.


> 4) Transactions
>

Agreed.

> 5) Real subtyping as discussed a few weeks ago *
>

I could go either way on this; any way you slice it subclassing is
going to be a mismatch to a relational database, but the current
system is needlessly confusing and could be cleaned up.

> 6) Proper schema checkpointing and transitioning *
>

This is also a big deal. Again, a lot of what makes this difficult
is coming to a community consensus on what "proper" is. However,
this is certainly something that could be added without sacrificing
backwards compatibility; I'd prefer to take a pass on this and push
it to 1.1.

> 7) Extract the admin history thing from manipulators into a
> seperate app*
>

I'm not sure why you feel this is necessary, but it also seems it
could be done with a minimum of backwards-incompatibility (rename
django_admin_log and refactor manipulators slightly). Database
evolution between versions of Django is probably OK as long as the
APIs stay the same.

> I was planning to do the * items in a branch before 1.0, with the
> explicit aim of doing every breaking change in one lump before 1.0
> so as
> to minimise the number of times people have to mess with their models.
>

I really appreciate your intentions, Robert, but going solo on big
features like this is a bad idea from a community standpoint. Many
of the changes you highlight are likely to be controversial and we
*have* to discuss them before they'll make it into Django. For
better or for worse, I don't want this to be the type of open source
project that rolls out big architectural changes without discussing
them with the community.

Reading over what I've written so far, it seems that I'm shying away
from difficult tasks. Perhaps I am, but the fact is that the longer
we linger in a pre-release stage the more our potential community
slips away. I don't use the number "1.0" lightly, and I know that it
locks us in somewhat, but that very lockin is what draws developers
to stable code. Most of the big feature you propose are things that
I would give my left thumb to see added to Django, but at the same
time I don't want Django to become a project that lingers in
perpetual pre-release. If we decide that these features can't be
done in a backwards-compatible way and have to release a 2.0 six
months after 1.0, what's the harm in that?

I've added http://code.djangoproject.com/wiki/VersionOneFeatures as a
way of taking a straw poll on what features people feel would be
neccisary to create before we can release a 1.0; I've tried to
summarize the feelings from this thread, so if I mistook anyone's
opinion I apologize in advance.

Thanks,

Jacob

[Robert Wittams]

+1, don't really care about the particular version number, just the
implications that it has for most people. ;-)

[Robert Wittams]

> If
> we decide that these features can't be done in a backwards-compatible
> way and have to release a 2.0 six months after 1.0, what's the harm in
> that?
>

Thats fine, but that needs to be made absolutely clear. The default that
people are going to expect is that we are "satisfied" with the
interfaces in Django 1.0, and they will be the focus for development for
a while .

I have nothing against releasing 1.0, but only *if* it is made clear
that it is not a long term maintenance release. I see no actual benefits
in releasing something called 1.0 without a back compat guarantee - I
really don't share your idea that you can't get a big community without
a 1.0 release. Just look -gasp- at Rails.

So if the 1.0 release is just a "look at me, I'm usable" release, then I
would cut down what I would like done from my last message to core
fields, subtyping. The other stuff can wait as long as 1.0 can be
semi-abandoned quite quickly.

>> 7) Extract the admin history thing from manipulators into a seperate
>app*
>>

>I'm not sure why you feel this is necessary, but it also seems it
>could be done with a minimum of backwards-incompatibility (rename
>django_admin_log and refactor manipulators slightly). Database
>evolution between versions of Django is probably OK as long as the
>APIs stay the same.

The only reason this is here rather than in new-admin is that it relies
on core fields being removed to do it sanely. It wouldn't actually have
to be backwards incompatible.

[Wilson Miner]

+1 for hugo's suggestion. A tarball now gives us a "stable" version to point people to before we start knocking off backwards-incompatible changes. A finalized roadmap for 1.0 puts the target in sight. And 0.9 says "we're almost there". All in favor

[Eugene Lazutkin]

"Jacob Kaplan-Moss" <ja...@jacobian.org> wrote in
message news:5C836A25-DD02-407A...@jacobian.org...

>
> Reading over what I've written so far, it seems that I'm shying away from
> difficult tasks. Perhaps I am, but the fact is that the longer we linger
> in a pre-release stage the more our potential community slips away. I
> don't use the number "1.0" lightly, and I know that it locks us in
> somewhat, but that very lockin is what draws developers to stable code.
> Most of the big feature you propose are things that I would give my left
> thumb to see added to Django, but at the same time I don't want Django to
> become a project that lingers in perpetual pre-release. If we decide
> that these features can't be done in a backwards-compatible way and have
> to release a 2.0 six months after 1.0, what's the harm in that?

+1.

Waxing philosophical: what version do we have now? 0.0? I didn't think we
were doing 0.x stuff. I did think of it as 1.0 Beta NNN because our goal is
1.0. When we will do incompatible changes after 1.0, it is not 1.x Rev MMM
anymore --- it is 2.0 Beta MMM.

Django was useable the first day it was published. To me that was 1.0
version even it was not called like that. Okay, let's call it 0.0 and
release 1.0 now incorporating small changes and adding a few documents. Why
bother with 0.9 stuff? It is just a name. All big stuff mentioned in this
thread is going to be rolled in and released as 2.0 as soon as it is
finished.

Thanks,

Eugene

[swrainey]

I'm a developer trying to choose what framework to use. I would like to
give my perspective on the situation. I would personally like to see
0.9 released real soon with a roadmap of what is coming for the 1.0
release and what might not be backwards compatible. I can easily see
that this framework has been proven on some high traffic sites and I
feel it's stable. Rails hasn't released 1.0 and it certianly has had
developer buy in. I think releasing the 0.9 and then the 1.0 will make
you look active and agressive.

I also think ajax is is more important than some others think. This is
probably just because there are a lot of other things that truly are
more important.

Ajax is really hot right now and I could see loosing some developers
because it's not as on the forefront of the whole web 2.0 hyped up
junk. Ajax is more about usability than eye candy or at least it should
be. That being said. I know I can use ajax really easy inside of a
django project but will anyone choose another framework based on most
of the other ones having "ajax support".

I think what you guys are going for is wanting developers to think that
your project is stable, relevant, and has a rapidly growing community.

I think you guys have done a great job and I look forward to seeing
this project progress.

[Simon Willison]

On 14 Nov 2005, at 07:10, swrainey wrote:

> Ajax is really hot right now and I could see loosing some developers
> because it's not as on the forefront of the whole web 2.0 hyped up
> junk. Ajax is more about usability than eye candy or at least it
> should
> be. That being said. I know I can use ajax really easy inside of a
> django project but will anyone choose another framework based on most
> of the other ones having "ajax support".

For me "Ajax support" really is pure marketing fluff - as far as I'm
concerned EVERY web framework supports Ajax unless it does something
truly moronic like refuse to let you output documents that don't have
the standard header/footer template.

That said, I know my way around JavaScript and prefer to write it by
hand. I imagine there are many developers out there who don't and
prefer having the framework do the work for them. The Ajax support in
Rails is my least favourite feature, precisely because I like to have
full control over how my JS works - but it makes a lot of Rails
developers very happy indeed.

At the very least, it is useful to have your framework make a few
decisions/recommendations for you - things like which XMLHttpRequest
cross-browser abstraction to use. I mould tend to look towards
MochiKit for that kind of thing since it's more Pythonic than other
JavaScript libraries, taking a lot of its ideas from Python features.

One thing that would be very cool would be some built in support in
Django for outputting JSON, which is a really neat format for sending
data to and from the server via XMLHttpRequest. Maybe a custom
template tag or filter would be useful here.

I know the Ajax in Django discussion has been going on for a long
time, but maybe it's time to take a closer look at it now that we're
thinking about features for 1.0. After all, in the ultra competitive
world of Web Frameworks marketing is important.

Cheers,

Simon

[Ian Holsman]

On 11/14/05, Simon Willison <swil...@gmail.com> wrote:

> For me "Ajax support" really is pure marketing fluff - as far as I'm
> concerned EVERY web framework supports Ajax unless it does something
> truly moronic like refuse to let you output documents that don't have
> the standard header/footer template.

At the point of a developer deciding, it's *ALL* about marketing.
You have about 2-3 clicks for him to decide if the framework is worth
looking further into.

Some developers think ajax is hot stuff, and it will make their app
look sexy in front of their PHB, so they want it supported out of the
box.

Others think it is a waste of space, and they can do the job better by
rolling their own.

this is the real 'marketing' question here..

Who do you want to use django?

If you want django to be popular and in wide use you will need to add
ajax support for those who want it.
The 'trick' i guess is how do you design the framework so it can have
ajax support, and the ability to turn it off.

regards
Ian

[Robert Wittams]

One thing to note here: When we get rid of core fields, we are going to
want to use both ajax & drag and drop in order to implement ticket #13.
It would be nice to use some "consistent" framework to do this, rather
than picking random bits of javascript up from around the internet.

Another thing to consider is ajax (pre-submit) form validation. So we do
have a need for goals within django itself which would best be served by
bundling a consistent js library set : its not just for users.

I think that Mochikit is probably the best option, being fairly light
and pythonic.

It doesn't include drag and drop or many effects - but it should be
possible to port anything we need from eg dojo or scriptaculous, and
maybe some turbogears people will beat us to it ;-P ).