Django and AJAX: Setting aside the conflict

[Wilson]

So far the discussion of "AJAX support" in Django has been a relatively
contentious one. There seem to be two viewpoints at the heart of this
conflict, which are not mutually exclusive in their substance. At the
risk of being unfair, let me grossly generalize the two positions.

1. AJAX is the future, and Django should be on board. AJAX may be
overhyped, but it's hyped for a reason. AJAX is a core component of
developing modern Web apps, and as a modern web framework Django should
support AJAX as a core feature.

2. Django already has all the AJAX support it needs.''' As a backend
framework, Django needs to provide data in a standard way that's easily
consumable by any AJAX toolkit (following the rule of loose coupling).
Since choosing wizzy frameworks is becoming a web development holy war,
Django should support any of them.

The root of the conflict here seems to be traceable to the fact that
AJAX, like pornography, has no clear definition. You know it when you
see it, and everybody sees something different.

With that in mind, let's see if we can work together here to get a
consensus on the goals of AJAX support in Django.

I've collected some of the posts from the list discussions onto a wiki
page that I hope will serve as a starting point.

http://code.djangoproject.com/wiki/AJAX

This is a naive attempt on my part, since I'm not a programmer, but I
am anxious to see this discussion move beyond (ahem) lively discussions
and into the realm of practical solutions.

I hope all of you with both an understanding of and an interest in this
will take it and run with it.

Cheers,
Wilson

[Robert Wittams]

Post by Wilson
So far the discussion of "AJAX support" in Django has been a relatively
contentious one. There seem to be two viewpoints at the heart of this
conflict, which are not mutually exclusive in their substance. At the
risk of being unfair, let me grossly generalize the two positions.
1. AJAX is the future, and Django should be on board. AJAX may be
overhyped, but it's hyped for a reason. AJAX is a core component of
developing modern Web apps, and as a modern web framework Django should
support AJAX as a core feature.
2. Django already has all the AJAX support it needs.''' As a backend
framework, Django needs to provide data in a standard way that's easily
consumable by any AJAX toolkit (following the rule of loose coupling).
Since choosing wizzy frameworks is becoming a web development holy war,
Django should support any of them.

Not to fan the flames, but I think my position has been a bit distinct
from these:

3. There are requirements for the bundled apps to make use of extensive
JS functionality. If we don't bundle an existing toolkit, we will end up
inventing a new one, or selling the bundled apps short. Not making a
decision does entail a cost.

[David Ascher]

Post by Robert Wittams
Not to fan the flames, but I think my position has been a bit distinct
3. There are requirements for the bundled apps to make use of extensive
JS functionality. If we don't bundle an existing toolkit, we will end up
inventing a new one, or selling the bundled apps short. Not making a
decision does entail a cost.
A related one is: when looking at building a webapp these days, one must

consider both server side framework choices and client side toolkits. Anyone
who'se put together products from several technology pieces knows that some
go together well, and some don't. In the case of Ajax, it strikes me that
there are pieces of the story where it'd be nice to know what the
"recommended" approach is. Django (and Rails, and Dojo) are in part going to
be successful because they free users from choice. So saying "whatever you
want" isn't actually what most people want to hear (myself included). I want
to trust experts to tell me what technologies I should bother
learning/investing in, in particular those that will save me time/effort.

I've been following Dojo for a while and Mochikit more recently, and while I
have no doubt that Mochikit will interface w/ Django just fine, I suspect
that with a little bit of work, Dojo+Django could make for a very compelling
solution, for example in autogeneration of client-side validation code
drivene from the Django introspection capabilities.

I also suggest that from a competitive marketing analysis, it'd be good to
figure out which of the Ajax capabilities that Rails claims make sense in
Django.

Regardless, this all seems tempest/teapoty.

Congratulations on the 0.90 release, btw!

--da

[Eugene Lazutkin]

While it does go against my beliefs, I have to admit that "freeing users from choice" works. At least it worked in case of TurboGears. In any case we have to provide "the preferred path" and document "the best practices". Documented way to do typical things always trumps "you can use whatever you want --- go and figure it out yourself" mantra. It helps to have at least some components are bundled together --- it reduces an acceptance barrier.

Let me take a stab at RoR Ajax. Unfortunately I have rather limited experience with RoR, so please correct me, if I am wrong. I hope somebody will explain TurboGears Ajax.

RoR supports Ajax by providing simple helpers in ActiveView (http://rails.rubyonrails.com/classes/ActionView/Helpers/JavaScriptHelper.html). It uses prototype.js. Visual features require inclusion of script.aculo.us. Following high-level features are covered:
a.. Drag-and-drop support: draggable elements and drop receiving elements can be specified in a template code. Dropping a draggable produces a callback specifying, which element was dropped.
b.. Asynchronous submission of regular forms.
c.. Observation of fields/forms: trigger a callback, when field/form was changed by user.
d.. Automatic support for simple sortable containers: order of elements can be changed by dragging them, it calls back when the order has changed.
Additionally a bunch of simple helpers are included: async callbacks by clicking links, periodic callbacks by timer, visual effects from scrip.aculo.us attached to events, automatic stubbing of server-side functions by wrapping XHR calls in JavaScript function, a shortcut to update HTML elements by executing a JavaScript code, which can come from server. The last one allows to provide a small set of useful transformations (e.g., show an error message), which can be used with different nodes.

OpenRico is experimenting with RoR as well (see http://richardcowin.typepad.com/blog/). I don't know details of their implementation.

In general there are several schools of thoughts on Ajax client-server integration. As you can see in many cases they don't contradict to each other, and can be implemented simultaneously. IMHO the most popular ones are:
a.. Shared objects, aka transparent remoting: JavaScript stub is produced automatically for server object, which redirects calls to the server, and any derivation of this approach. It is useful when you request features/properties of remote object dynamically and don't know what properties are going to be required. Such object can implement simple caching mechanism to avoid repeated calls.
b.. Managed object publishing: server side objects are marked as Ajax-enabled, and system provides some unified way to access them. The system discovers all such objects and publish them using RESTful API. Example: /ajax/blog/post_id/update will call update() method of blog object identified by post_id. Parameters are POSTed or in the URL. Of course, blog class should be marked as Ajax-enabled, and update() should be marked as Ajax-public. It's kind of similar to Eric Moritz implementation. (Sidenote: personally I prefer URIs like that: /blog/ajax/post_id/update to contain all module-related functionality under /module/.)
c.. Server-backed widgets: client side objects (widgets) assume some API from related server object, which is identified by its URI. Example: auto-suggest widget may assume that the server side object supports calls like URI/suggest.html?limit=10&startwith=pattern. In this case a simple set of widgets can work with any object, which implements this API. In case of Django as a backend :-), it may form parameters for get_object()/get_list() directly.
I think it is enough for now. I hope somebody will add to this list. Any thoughts?

Thanks,

Eugene
"David Ascher" <david.ascher-***@public.gmane.org> wrote in message news:dd28fc2f0511161021v4bfd195cxed450163a158d77b-JsoAwUIsXouq+1Nelnf3ueG/***@public.gmane.org
On 11/16/05, Robert Wittams <robert-XygGVys+***@public.gmane.org> wrote:
Not to fan the flames, but I think my position has been a bit distinct
from these:

3. There are requirements for the bundled apps to make use of extensive
JS functionality. If we don't bundle an existing toolkit, we will end up
inventing a new one, or selling the bundled apps short. Not making a
decision does entail a cost.


A related one is: when looking at building a webapp these days, one must consider both server side framework choices and client side toolkits. Anyone who'se put together products from several technology pieces knows that some go together well, and some don't. In the case of Ajax, it strikes me that there are pieces of the story where it'd be nice to know what the "recommended" approach is. Django (and Rails, and Dojo) are in part going to be successful because they free users from choice. So saying "whatever you want" isn't actually what most people want to hear (myself included). I want to trust experts to tell me what technologies I should bother learning/investing in, in particular those that will save me time/effort.

I've been following Dojo for a while and Mochikit more recently, and while I have no doubt that Mochikit will interface w/ Django just fine, I suspect that with a little bit of work, Dojo+Django could make for a very compelling solution, for example in autogeneration of client-side validation code drivene from the Django introspection capabilities.

I also suggest that from a competitive marketing analysis, it'd be good to figure out which of the Ajax capabilities that Rails claims make sense in Django.

Regardless, this all seems tempest/teapoty.

Congratulations on the 0.90 release, btw!

--da

[Jacob Kaplan-Moss]

Eugene --

Can you add this to the discussion on the wiki?

Thanks,

Jacob

[Eugene Lazutkin]

Will do. I was hoping that it would be discussed publicly before being
canned.

Post by Jacob Kaplan-Moss
Eugene --
Can you add this to the discussion on the wiki?
Thanks,
Jacob

[Jacob Kaplan-Moss]

Post by Eugene Lazutkin
Will do. I was hoping that it would be discussed publicly before being
canned.

I didn't mean to "can" anything -- I think your assesment of what's
good about AJAX in Rails is quite useful, so I want it somewhere
slightly more prominent than the mail list. Since this is a big
issue with lots of thorns I'm trying to make sure all the important
info gets onto that wiki page so we can all chew on it.

Jacob

[Eugene Lazutkin]

Done.

I think that RoR's implementation is a little bit clunky:

1) too many callbacks, which may be processed on client side
2) too low level
3) unmodular on client side

Of course you can always write your own level, which will keep things
manageable in complex cases. Unfortunately RoR does come bundled with them.
Script.aculo.us and OpenRico take care of some high-level stuff, but while
they provide some widgets, they lack unified widget building system.

I think that the most clever part of RoR's Ajax is simple yet efficient drag
and drop support.

If you formulate RoR's Ajax functionality in terms of widgets it comes to:

1) Widget XXX provides YYY functionality.
2) There is a markup code to specify a widget with all required parameters
in your HTML.
3) Widget may do callbacks on certain (high-level) events.
4) Widget can be as simple or as complex as possible.

Thanks,

Eugene

Post by Eugene Lazutkin
Will do. I was hoping that it would be discussed publicly before being
canned.

I didn't mean to "can" anything -- I think your assesment of what's good
about AJAX in Rails is quite useful, so I want it somewhere slightly more
prominent than the mail list. Since this is a big issue with lots of
thorns I'm trying to make sure all the important info gets onto that wiki
page so we can all chew on it.
Jacob

[Wilson]

See what I mean? ;) Of course, everyone with a real opinion will
ultimately fall somewhere between the two.

Opinions aside, I guess what I was trying to say is let's talk nuts and
bolts. You know, instead of apples and oranges.

[Robert Wittams]

Post by Wilson
See what I mean? ;) Of course, everyone with a real opinion will
ultimately fall somewhere between the two.
Opinions aside, I guess what I was trying to say is let's talk nuts and
bolts. You know, instead of apples and oranges.

Erm, my point was really contained in the word 'distinct', not all
points of view can be boiled down to a continuum between two extremes.

No one has even attempted to respond to the bundled apps problem,
instead people are just waxing lyrical about the benefits of letting
users choose any lump of Javascript they fancy.

[Wilson]

Honestly, I'm not really sure what you're after. Yes, everyone's
opinion is distinct. I think that's clear from the preceding
discussions. I'm just saying it might be productive to focus on what we
can and do agree on and act on that.

Far from being ignored, as far as I can tell, most of the conversation
(and argument) so far has revolved around the "bundled apps" problem.
But no matter which framework gets bundled (or if anything gets bundled
at all) the exact same work is going to be necessary on the backend
first.

So all I'm saying is let's get started on that, and we can all argue
about which framework is better once there's some working code in the
bag, or at least a concrete plan.

[Eugene Lazutkin]

Inline.

Post by Wilson
But no matter which framework gets bundled (or if anything gets bundled
at all) the exact same work is going to be necessary on the backend
first.

All toolkits have different ways to make their magic. While it may be
possible to be library-agnostic in general code, it may not be possible for
concrete application. Unfortunately application-specific JavaScript will be
different for different frameworks, and amount of it depends on selected
toolkit.

Another point: even if you have some magic code, which works with any
toolkit, you have to bundle this "any toolkit". Otherwise Admin will not
work out of box. I don't think it is acceptable.

Robert is right asking to make a choice.

Thanks,

Eugene

[Robert Wittams]

Post by Wilson
no matter which framework gets bundled (or if anything gets bundled
at all)

This is the sticking point. I just have no idea how we add rich
functionality to the bundled apps without either

a) Picking a toolkit to bundle
b) Making some horrific abstraction layer over every bit of vaguely
advanced JS functionality so as not to offend any toolkit fans
c) Making our own pointlessly limited toolkit with all the bugs and
browser workarounds that every toolkit has to address

I'm sure people are convinced I'm just arguing for the sake of it, but I
really am trying to get across a point which just hasn't been addressed
by people who want to be toolkit-agnostic to the max.

[hugo]

Post by Robert Wittams
I'm sure people are convinced I'm just arguing for the sake of it, but I
really am trying to get across a point which just hasn't been addressed
by people who want to be toolkit-agnostic to the max.

I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else. So just select one
for the Django admin stuff and build stuff around that one. But just
keep in mind that things should at least have lower-level APIs that
could be used even if the selected toolkit isn't used itself, but some
other toolkit is. Sure, people won't be able to use all aspects of
Django when switching toolkits - but that's the same with ORM and
template system, you just can't use all aspects of Django when
switching them to SQLObject or Cheetah.

bye, Georg

[James Bennett]

Post by hugo
keep in mind that things should at least have lower-level APIs that
could be used even if the selected toolkit isn't used itself, but some
other toolkit is.

Again, +1. Some sort of (hopefully RESTful) API which can respond to
queries and toss back a chunk of XML or JSON would be the ideal, I
think. That way Django can bundle whatever ends up being preferred,
but developers who don't want to use it aren't too terribly penalized
because they can still build AJAX into their applications.

And building an API like that probably wouldn't be too difficult; a
rough version (but robust enough to do, say, the "live archives" that
are popular in certain blog systems) could easily be implemented right
now just by hooking generic views into templates which return the data
in the appropriate format.

And yes, I misspoke the other day when I referred to Protoype, but
meant scriptaculous -- the latter is the one which has both AJAX
functions (via Prototype) and a variety of solif visual DHTML effects.


--
"May the forces of evil become confused on the way to your house."
-- George Carlin

[Wilson Miner]

Post by hugo
I think we should be as toolkit-agnostic as we are

templatesystem-agnostic and ORM-agnostic. We deliver one with Django,

Post by hugo
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else.

+1 - well put

[Pedro Furtado]

Post by Wilson Miner

Post by hugo
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else.

+1 - well put

+1 too.

--
Pedro

[Amit Upadhyay]

Here are my half cooked thought on the issue.

Post by hugo
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,

Post by hugo
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else.

We are asking the wrong question. Let me make a statement: Any AJAX support
in django will modified/enhanced Django Template System.

The modifications will be in the form of new tags being added to core or
contrib, and we can have a set of tags for each javascript toolkit based on
their merits and user demand, and designing everything with that in
mind/docs would be the way to go.

I have been reading http://code.djangoproject.com/wiki/AJAX and I don't much
like the "Proposed Implementation".

1)

Please read my comments on http://code.djangoproject.com/ticket/552,
http://code.djangoproject.com/ticket/547 and
http://code.djangoproject.com/ticket/356 to see how I think RPC should be
done, and not as suggested in the "The second layer will be a set of views"
in the Wiki. Thinking having access to modems from javascript is a magic
solution, is tempting but wrong. There will be situations where you would
want methods to be accessible from webservice, and putting all such possible
methods in the models is not the right thing to do.
**
So my implementation of django will have SimpleJSONView in the lines of
http://code.djangoproject.com/ticket/552 , where you would register
functions/objects to it, and they will then be available as json webservice.

2)

Then I have problem with:

The idea is that in Javascript I should be able to do::

entries = rpc.get_list('blogs.entries', {'limit' : 15})

(or something) and have it Just Work™.

First of all that would be a blocking call, and blocking javascript call
have undefined behavoiur on different browsers, they may stop all other
onmousovers, not a good thing. So we will have to use
deferreds<http://mochikit.com/doc/html/MochiKit/Async.html#deferred>.
But I guess this is just some technicality implied in "(or something)". What
I am trying to say is we may not be able to have a one to one mapping
between way of doing thing in python with those of that we have in
javascript.

Now about the myth that JSON or Javascript or XML for that matter, will have
anything to do with my idea of AJAX implementation in Django. It wont:

I completely love the work in rails, its extremely brilliant. When people
think of AJAX they think of "oh I will put a onclick or something similar,
call a javascript methods provided by django-ajax support, get results not
in XML but json which can be passed through eval and get javascript
values/objects, and "do some logic" and finally update some div". Now this
is very wrong:
1) it makes you spend a lot of time in javascript, which I do not consider a
good language for programming, or at least no as good as python
2) Generating HTML becomes a mix of working with DOM that we do in client
side javascript world with the html template world in the django-python
side.

Now the earth shattering revolution that rails did is say most of the time
"do some logic" will just be "convert the javascript/xml passed returned by
server call to dom/html". By this brilliant stroke they have completely
eliminated the requirement to have to do anything with javascript in AJAX,
for most part. This is the reason people love Rails AJAX support. With that
in mind they went ahead and said all server calls will lead to updating a
div, these updates could one of the following: 'replace', 'append',
'prepend', 'insert_after', 'insert_before'.

If we agree with these, the views would be normal django views, returning
html, which we generate using normal django templates, as we always do, and
these html snippets will be used to update the above mentioned div.

So my proposed solution:

We create the tags:

<% dojo_include_tag %> it will expand to html/javascript to include dojo
related libraries.

<% dojo_link_to_remote "Delete this post",
:url => { :action => "destroy", :id => post.id <http://post.id> },
:update => { :success => "posts", :failure => "error" } %>

And so on, basically borrowing them from
rails<http://api.rubyonrails.com/classes/ActionView/Helpers/JavaScriptHelper.html>.
We will probably need a little different naming convention than rails as
rails names are adhoc-ish while django names are typically much more
elegant.

Also we can have a similar set of mochikit_* and prototype_* functions and
people can decide what they want to use.

The advantages:

1) Other than adding a set of tags, django is not touched.
2) You can add your set of tags deriving from the ones provided by django if
you do not like the toolkit used by django, without losing anything at all,
so its more like mysql-vs-pgsql, where we do not lose any thing, as against
django orm vs sqlobject where we do lose many things.
3) Using AJAX for a large part with django will become an issue of modifying
templates, and no user level javascript programming is required for a large
part, tho is always available.


There are lots of details to be worked out, but these are my ideas.

--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay<http://www.rootshell.be/%7Eupadhyay>
[phone]

[Eugene Lazutkin]

Let me present my half-cooked view of the layers.

I don't care how many layers we are going to have in implementation, I care for the final layer --- actual use of Ajax in templates. RPC is not a final layer for me, because I suspect that majority of user will need end user functionality, which is more high-level than RPC.

1) JavaScript as bad, blah-blah-blah, python is good, blah-blah-blah. Guess what, I want to minimize the use of both and concentrate on my business logic. I want to be able to tell GUI designer (or myself): "Use this magic string for autosuggest widget, and this gizmo for a tree."

2) Ultimately I want to see (pseudo-code): <% autosuggest URI params %>.

3) Autosuggest will generate some simple HTML fragment (pseudo-code): <div widget="autosuggest" from="URI" params="..."></div>

4) Autosuggest widget will take care about visual representation according to parameters and will use specified URI to get its data.

In this case end users of all Ajaxy stuff can use it without being js/python adepts. All implementation-specific details (e.g., correct handling of asynchronous calls, using right visuals for pop-up suggestions, selection, DOM manipulation, delays before requesting data, and so on) should be handled by the widget itself. If we are talking about Dojo as a bundled library, they already have similar widget, which they call ComboBox. It can be used as a foundation.

My point is RPC is not the whole picture. That's why I didn't like RoR's implementation --- it's too low-level. Obviously you can build on it but it requires a certain level of knowledge you don't need. Use of simple stuff should be, well, simple.

The Proposed implementation is a proposal, nothing more. It's too vague to serve as an actual blueprint. But it is better than nothing. Hugo and you have some good RPC ideas. If any proposed implementation has a contradiction with good RPC implementation, let's correct it. But let's keep my dream alive. :-)

BTW, who said that Ajax will use full-blown RPC like SOAP for its magic and JSON/XML as a transport? I think that both RPC and Ajax should built on more light weight foundation. In case of autosuggest widget it may make sense to receive HTML instead of JSON, which is formed by my application-specific template and presents data exactly how I need it to be presented, e.g., with additional information, pictures, and so on. Same goes for tree widget.

Thanks,

Eugene
"Amit Upadhyay" <upadhyay-***@public.gmane.org> wrote in message news:349edb380511180252y2626c57y41c588cc5658901b-JsoAwUIsXouq+1Nelnf3ueG/***@public.gmane.org
Here are my half cooked thought on the issue.

On 11/18/05, Wilson Miner <wminer-***@public.gmane.org > wrote:
I think we should be as toolkit-agnostic as we are

templatesystem-agnostic and ORM-agnostic. We deliver one with Django,
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else.



We are asking the wrong question. Let me make a statement: Any AJAX support in django will modified/enhanced Django Template System.

The modifications will be in the form of new tags being added to core or contrib, and we can have a set of tags for each javascript toolkit based on their merits and user demand, and designing everything with that in mind/docs would be the way to go.

I have been reading http://code.djangoproject.com/wiki/AJAX and I don't much like the "Proposed Implementation".

1)

Please read my comments on http://code.djangoproject.com/ticket/552, http://code.djangoproject.com/ticket/547 and http://code.djangoproject.com/ticket/356 to see how I think RPC should be done, and not as suggested in the "The second layer will be a set of views" in the Wiki. Thinking having access to modems from javascript is a magic solution, is tempting but wrong. There will be situations where you would want methods to be accessible from webservice, and putting all such possible methods in the models is not the right thing to do.


So my implementation of django will have SimpleJSONView in the lines of http://code.djangoproject.com/ticket/552 , where you would register functions/objects to it, and they will then be available as json webservice.

2)

Then I have problem with:

The idea is that in Javascript I should be able to do::
entries = rpc.get_list('blogs.entries', {'limit' : 15})(or something) and have it Just Work™.

First of all that would be a blocking call, and blocking javascript call have undefined behavoiur on different browsers, they may stop all other onmousovers, not a good thing. So we will have to use deferreds. But I guess this is just some technicality implied in "(or something)". What I am trying to say is we may not be able to have a one to one mapping between way of doing thing in python with those of that we have in javascript.

Now about the myth that JSON or Javascript or XML for that matter, will have anything to do with my idea of AJAX implementation in Django. It wont:

I completely love the work in rails, its extremely brilliant. When people think of AJAX they think of "oh I will put a onclick or something similar, call a javascript methods provided by django-ajax support, get results not in XML but json which can be passed through eval and get javascript values/objects, and "do some logic" and finally update some div". Now this is very wrong:
1) it makes you spend a lot of time in javascript, which I do not consider a good language for programming, or at least no as good as python
2) Generating HTML becomes a mix of working with DOM that we do in client side javascript world with the html template world in the django-python side.

Now the earth shattering revolution that rails did is say most of the time "do some logic" will just be "convert the javascript/xml passed returned by server call to dom/html". By this brilliant stroke they have completely eliminated the requirement to have to do anything with javascript in AJAX, for most part. This is the reason people love Rails AJAX support. With that in mind they went ahead and said all server calls will lead to updating a div, these updates could one of the following: 'replace', 'append', 'prepend', 'insert_after', 'insert_before'.

If we agree with these, the views would be normal django views, returning html, which we generate using normal django templates, as we always do, and these html snippets will be used to update the above mentioned div.

So my proposed solution:

We create the tags:

<% dojo_include_tag %> it will expand to html/javascript to include dojo related libraries.

<% dojo_link_to_remote "Delete this post",
:url => { :action => "destroy", :id => post.id },
:update => { :success => "posts", :failure => "error" } %>

And so on, basically borrowing them from rails. We will probably need a little different naming convention than rails as rails names are adhoc-ish while django names are typically much more elegant.

Also we can have a similar set of mochikit_* and prototype_* functions and people can decide what they want to use.

The advantages:

1) Other than adding a set of tags, django is not touched.
2) You can add your set of tags deriving from the ones provided by django if you do not like the toolkit used by django, without losing anything at all, so its more like mysql-vs-pgsql, where we do not lose any thing, as against django orm vs sqlobject where we do lose many things.
3) Using AJAX for a large part with django will become an issue of modifying templates, and no user level javascript programming is required for a large part, tho is always available.


There are lots of details to be worked out, but these are my ideas.

--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
[phone]

[David Ascher]

Post by Eugene Lazutkin
I don't care how many layers we are going to have in implementation, I
care for the final layer --- actual use of Ajax in templates. RPC is not a
final layer for me, because I suspect that majority of user will need *end
user* functionality, which is more high-level than RPC.

etc. I love this vision, and would be happy to help make it happen. I agree
wholeheartedly that the end-user of this stuff should not need to know most
of what the implementers will need to.

--da

[Eugene Lazutkin]

Let me present my half-cooked view of the layers.

I don't care how many layers we are going to have in implementation, I care for the final layer --- actual use of Ajax in templates. RPC is not a final layer for me, because I suspect that majority of user will need end user functionality, which is more high-level than RPC.

1) JavaScript as bad, blah-blah-blah, python is good, blah-blah-blah. Guess what, I want to minimize the use of both and concentrate on my business logic. I want to be able to tell GUI designer (or myself): "Use this magic string for autosuggest widget, and this gizmo for a tree."

2) Ultimately I want to see (pseudo-code): <% autosuggest URI params %>.

3) Autosuggest will generate some simple HTML fragment (pseudo-code): <div widget="autosuggest" from="URI" params="..."></div>

4) Autosuggest widget will take care about visual representation according to parameters and will use specified URI to get its data.

In this case end users of all Ajaxy stuff can use it without being js/python adepts. All implementation-specific details (e.g., correct handling of asynchronous calls, using right visuals for pop-up suggestions, selection, DOM manipulation, delays before requesting data, and so on) should be handled by the widget itself. If we are talking about Dojo as a bundled library, they already have similar widget, which they call ComboBox. It can be used as a foundation.

My point is RPC is not the whole picture. That's why I didn't like RoR's implementation --- it's too low-level. Obviously you can build on it but it requires a certain level of knowledge you don't need. Use of simple stuff should be, well, simple.

The Proposed implementation is a proposal, nothing more. It's too vague to serve as an actual blueprint. But it is better than nothing. Hugo and you have some good RPC ideas. If any proposed implementation has a contradiction with good RPC implementation, let's correct it. But let's keep my dream alive. :-)

BTW, who said that Ajax will use full-blown RPC like SOAP for its magic and JSON/XML as a transport? I think that both RPC and Ajax should built on more light weight foundation. In case of autosuggest widget it may make sense to receive HTML instead of JSON, which is formed by my application-specific template and presents data exactly how I need it to be presented, e.g., with additional information, pictures, and so on. Same goes for tree widget.

Thanks,

Eugene

"Amit Upadhyay" <upadhyay-***@public.gmane.org> wrote in message news:349edb380511180252y2626c57y41c588cc5658901b-JsoAwUIsXouq+1Nelnf3ueG/***@public.gmane.org
Here are my half cooked thought on the issue.

On 11/18/05, Wilson Miner <wminer-***@public.gmane.org > wrote:
I think we should be as toolkit-agnostic as we are

templatesystem-agnostic and ORM-agnostic. We deliver one with Django,
and all Django code builds on the delivered ones. But we don't enforce
those on users, if they want to use something else.



We are asking the wrong question. Let me make a statement: Any AJAX support in django will modified/enhanced Django Template System.

The modifications will be in the form of new tags being added to core or contrib, and we can have a set of tags for each javascript toolkit based on their merits and user demand, and designing everything with that in mind/docs would be the way to go.

I have been reading http://code.djangoproject.com/wiki/AJAX and I don't much like the "Proposed Implementation".

1)

Please read my comments on http://code.djangoproject.com/ticket/552, http://code.djangoproject.com/ticket/547 and http://code.djangoproject.com/ticket/356 to see how I think RPC should be done, and not as suggested in the "The second layer will be a set of views" in the Wiki. Thinking having access to modems from javascript is a magic solution, is tempting but wrong. There will be situations where you would want methods to be accessible from webservice, and putting all such possible methods in the models is not the right thing to do.


So my implementation of django will have SimpleJSONView in the lines of http://code.djangoproject.com/ticket/552 , where you would register functions/objects to it, and they will then be available as json webservice.

2)

Then I have problem with:

The idea is that in Javascript I should be able to do::
entries = rpc.get_list('blogs.entries', {'limit' : 15})(or something) and have it Just Work™.

First of all that would be a blocking call, and blocking javascript call have undefined behavoiur on different browsers, they may stop all other onmousovers, not a good thing. So we will have to use deferreds. But I guess this is just some technicality implied in "(or something)". What I am trying to say is we may not be able to have a one to one mapping between way of doing thing in python with those of that we have in javascript.

Now about the myth that JSON or Javascript or XML for that matter, will have anything to do with my idea of AJAX implementation in Django. It wont:

I completely love the work in rails, its extremely brilliant. When people think of AJAX they think of "oh I will put a onclick or something similar, call a javascript methods provided by django-ajax support, get results not in XML but json which can be passed through eval and get javascript values/objects, and "do some logic" and finally update some div". Now this is very wrong:
1) it makes you spend a lot of time in javascript, which I do not consider a good language for programming, or at least no as good as python
2) Generating HTML becomes a mix of working with DOM that we do in client side javascript world with the html template world in the django-python side.

Now the earth shattering revolution that rails did is say most of the time "do some logic" will just be "convert the javascript/xml passed returned by server call to dom/html". By this brilliant stroke they have completely eliminated the requirement to have to do anything with javascript in AJAX, for most part. This is the reason people love Rails AJAX support. With that in mind they went ahead and said all server calls will lead to updating a div, these updates could one of the following: 'replace', 'append', 'prepend', 'insert_after', 'insert_before'.

If we agree with these, the views would be normal django views, returning html, which we generate using normal django templates, as we always do, and these html snippets will be used to update the above mentioned div.

So my proposed solution:

We create the tags:

<% dojo_include_tag %> it will expand to html/javascript to include dojo related libraries.

<% dojo_link_to_remote "Delete this post",
:url => { :action => "destroy", :id => post.id },
:update => { :success => "posts", :failure => "error" } %>

And so on, basically borrowing them from rails. We will probably need a little different naming convention than rails as rails names are adhoc-ish while django names are typically much more elegant.

Also we can have a similar set of mochikit_* and prototype_* functions and people can decide what they want to use.

The advantages:

1) Other than adding a set of tags, django is not touched.
2) You can add your set of tags deriving from the ones provided by django if you do not like the toolkit used by django, without losing anything at all, so its more like mysql-vs-pgsql, where we do not lose any thing, as against django orm vs sqlobject where we do lose many things.
3) Using AJAX for a large part with django will become an issue of modifying templates, and no user level javascript programming is required for a large part, tho is always available.


There are lots of details to be worked out, but these are my ideas.

--
Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay
[phone]

[Robert Wittams]

Post by hugo
Sure, people won't be able to use all aspects of
Django when switching toolkits - but that's the same with ORM and
template system, you just can't use all aspects of Django when
switching them to SQLObject or Cheetah.

Exactly ;-)

[Bill de hÓra]

Post by Robert Wittams

Post by Wilson
no matter which framework gets bundled (or if anything gets bundled
at all)

This is the sticking point. I just have no idea how we add rich
functionality to the bundled apps without either
a) Picking a toolkit to bundle
b) Making some horrific abstraction layer over every bit of vaguely
advanced JS functionality so as not to offend any toolkit fans
c) Making our own pointlessly limited toolkit with all the bugs and
browser workarounds that every toolkit has to address

Turn it around. Which of the javascript stacks is working now, or is
willing to work, to make it kick ass with Django?

cheers
Bill

[David Ascher]

Post by Bill de hÓra
Turn it around. Which of the javascript stacks is working now, or is
willing to work, to make it kick ass with Django?

I won't speak for him, but I was talking last night to Alex Russell, of
Dojo, and he said that he'd tried to talk to the Django folks a few months
ago, and I guess that didn't go very far. I'm working on getting him to take
another look (in part because I think Dojo could learn from Django when it
comes to docs!). I do think that he's more than happy to work w/ Django to
see where there would be a fit. They are naturally not likely to want to
make Dojo work "only" with Django (nor does anyone likely want that).

I sent Alex the comment that Eugene made yesterday re "looks like it fits
like a glove" in the context of validation, and his reaction was "Cool.".

I'm happy to see Django folks looking at Dojo (& others, of course), and
happy to see Alex interested in figuring out Django. I think the two groups
have very compatible philosophies, from what I can tell so far.

--david

[Eugene Lazutkin]

Not true! I support your position. While we attempt to make Django
library-agnostic, let's settle on what is going to be used in bundled apps.
IMHO admin should be used as a field test of design decisions and a source
of new ideas. Maybe it would be useful to compile a list of required widgets
(e.g., reorderable list) and required functionality (e.g., client-side
validators) first.

I propose to use Dojo for new-new-admin. I presented my reasoning before.

Thanks,

Eugene

PS: There are some people in Dojo community, who work on form widget, which
supports some validation mechanism. It would be nice to see what they do.

Post by Robert Wittams

Post by Wilson
See what I mean? ;) Of course, everyone with a real opinion will
ultimately fall somewhere between the two.
Opinions aside, I guess what I was trying to say is let's talk nuts and
bolts. You know, instead of apples and oranges.

Erm, my point was really contained in the word 'distinct', not all
points of view can be boiled down to a continuum between two extremes.
No one has even attempted to respond to the bundled apps problem,
instead people are just waxing lyrical about the benefits of letting
users choose any lump of Javascript they fancy.

[Eugene Lazutkin]

Sorry for replying to myself.

Post by Eugene Lazutkin
PS: There are some people in Dojo community, who work on form widget,
which supports some validation mechanism. It would be nice to see what
they do.

They do have some stuff to validate input. I found this file in their
repository:

http://dojotoolkit.org/trac/file/trunk/src/validate.js

It reminds me of:

http://code.djangoproject.com/browser/django/trunk/django/core/validators.py

Their code can validate individual values as well as all fields of the form
using some additonal meta-information.

Thanks,

Eugene

[Jonathan Daugherty]

# Sorry for replying to myself.

Don't apologize to us; apologize to yourself!

[David Ascher]

Post by Eugene Lazutkin

Post by Eugene Lazutkin
PS: There are some people in Dojo community, who work on form widget,
which supports some validation mechanism. It would be nice to see what
they do.

They do have some stuff to validate input. I found this file in their
http://dojotoolkit.org/trac/file/trunk/src/validate.js
http://code.djangoproject.com/browser/django/trunk/django/core/validators.py
Their code can validate individual values as well as all fields of the form
using some additonal meta-information.

Goofy idea: use the Python logic to generate JS code to do clientside
validation based on the model-specified constraints. Detailed specification
and implementation are left as an exercise to the reader. ;-)

[Eugene Lazutkin]

I don't think it's goofy idea. Actually it is kind of what dojo.validate.check() does: it takes a form id and a profile object, which tells how to validate each field. Obviously the profile is generated by server depending on underlying data types. Django has all information available to generate it.

As I can see they support individual validations, some dependency validations, equality validations (double checks), and pre-filtering (e.g., trim whitespaces, upper/lowercase, and so on). So far it fits Django like a glove.

Thanks,

Eugene

Post by Eugene Lazutkin
PS: There are some people in Dojo community, who work on form widget,
which supports some validation mechanism. It would be nice to see what
they do.

They do have some stuff to validate input. I found this file in their
repository:

http://dojotoolkit.org/trac/file/trunk/src/validate.js

It reminds me of:

http://code.djangoproject.com/browser/django/trunk/django/core/validators.py

Their code can validate individual values as well as all fields of the form
using some additonal meta-information.

Goofy idea: use the Python logic to generate JS code to do clientside validation based on the model-specified constraints. Detailed specification and implementation are left as an exercise to the reader. ;-)

[Simon Willison]

Post by David Ascher
Goofy idea: use the Python logic to generate JS code to do
clientside validation based on the model-specified constraints.
Detailed specification and implementation are left as an exercise
to the reader. ;-)

Here's a concept for form validation with Ajax I've been knocking
around for ages that I would love to see in Django.

The most annoying thing about client-side validation is having to
duplicate the logic used in your server-side validation code.
Automating this is a nice idea but suffers from a couple of pretty
big problems:

1. Differences between JavaScript and Python regular expression syntax
2. Some checks, such as "is this user name already taken", can only
happen with server involvement

Here's how to fix both of these: have the client-side validation run
against the server-side validation logic using Ajax to communicate
between the two.

Say you have a form that submits to here:

/add-blog-entry/submit/

First, add another end point:

/add-blog-entry/validate/ (or validate_json or whatever)

Associate a pre-written (generic?) view with that end point that is
itself associated with a set of validation rules - in Django terms
that would probably be a manipulator of some sort. Every time a form
field is filled in the blur event causes JS to post the field name
and the data from that field at the validate endpoint. It returns a
simple JSON object representing if the data was valid, invalid or
undetermined (for fields which can't be validated without seeing
information from elsewhere in the form - we probably don't want to
send all form field data at once for every validation call as forms
involving big textareas can end up with a lot of data in them).
Invalid responses are accompanied by a JSON array of human readable
error messages.

JavaScript code on the client can then add green ticks or red crosses
to fields indicating valid and invalid data.

Cheers,

Simon

[Christopher Lenz]

Post by Simon Willison

Post by David Ascher
Goofy idea: use the Python logic to generate JS code to do
clientside validation based on the model-specified constraints.
Detailed specification and implementation are left as an exercise
to the reader. ;-)

Here's a concept for form validation with Ajax I've been knocking
around for ages that I would love to see in Django.
The most annoying thing about client-side validation is having to
duplicate the logic used in your server-side validation code.
Automating this is a nice idea but suffers from a couple of pretty
1. Differences between JavaScript and Python regular expression syntax
2. Some checks, such as "is this user name already taken", can only
happen with server involvement
Here's how to fix both of these: have the client-side validation
run against the server-side validation logic using Ajax to
communicate between the two.

While there are definitely many types of validations that can't be
performed on the client side, calling back to the server just to
check whether e.g. a text-input is empty is overkill IMO. The same
goes for validity checks for common things like text fields expecting
an email address or date.

I'd prefer a hybrid approach, where simple javascript validation
checks are generated, and the others are performed via AJAX callbacks.

Post by Simon Willison
Associate a pre-written (generic?) view with that end point that is
itself associated with a set of validation rules - in Django terms
that would probably be a manipulator of some sort. Every time a
form field is filled in the blur event causes JS to post the field
name and the data from that field at the validate endpoint. It
returns a simple JSON object representing if the data was valid,
invalid or undetermined (for fields which can't be validated
without seeing information from elsewhere in the form - we probably
don't want to send all form field data at once for every validation
call as forms involving big textareas can end up with a lot of data
in them). Invalid responses are accompanied by a JSON array of
human readable error messages.

Validation starts to get interesting when it involves relations
between multiple field, for example one field must be non-empty and
contain a date, but only if some checkbox is checked. It'd be
interesting if such relations could somehow be expressed, so that the
server callback would get all the data it needs for the validation,
and not more.

OTOH, the validation in this example would ideally not even get
triggered, because the date text field would be disabled until the
checkbox got checked :-P A better example is probably the classic
"matching passwords" validation.

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

[Eugene Lazutkin]

Inline.

I'd prefer a hybrid approach, where simple javascript validation checks
are generated, and the others are performed via AJAX callbacks.

+1.

Well-known type validation and simple checks can be (and should be) done
client-side. Complex validation should be:

1) done by server using callback from the client, server should specify
which fields it wants to see
2) done by client using meta information provided by server

OTOH, the validation in this example would ideally not even get
triggered, because the date text field would be disabled until the
checkbox got checked :-P A better example is probably the classic
"matching passwords" validation.

It is a good idea. I wonder if we have all info available to generate such
code or a helper for such code. In one of my projects I didn't show form
fields, which didn't make sense given user's input so far. It prevented
user's confusing and reduced number of presented fields by 50-70% making the
form compact and observable. I coded this code manually. It would be nice to
automate it somehow.

Thanks,

Eugene

[Antonio Cavedoni]

Hello everyone,

first post on the list, I’ll be introducing myself at the bottom of
this message.

Post by Christopher Lenz
While there are definitely many types of validations that can't be
performed on the client side, calling back to the server just to
check whether e.g. a text-input is empty is overkill IMO. The same
goes for validity checks for common things like text fields
expecting an email address or date.
I'd prefer a hybrid approach, where simple javascript validation
checks are generated, and the others are performed via AJAX callbacks.

I don’t agree with this approach. While I think client-side
validation is fine and dandy, and from a user perspective is
definitely the way to go, we cannot rely on it.

It’s not like we’re in 1999 when we could develop a “DHTML”-
cool-whiz-bang inaccessible piece of crap and still expect to get
along with it. We’re in 2005, and we *know* that some people turn JS
off on purpose, use browsers where JS support sucks, or are disabled
and we cannot feed them some of the “dynamic” stuff we think is so
cool, because they just won’t be able to use it.

We also don’t want to have to mantain the same code in two places:
email-validation in JS on the client and email-validation on the
server (yes, I’m oversimplifying, but you get the idea).

So I think the best way for Django, “the web framework for
perfectionists with deadlines” is to do The Right Thing™ and have
some sort of support for dynamic, JS-based form validation on the
client powered by the same logic that powers the server-side, and
this is where JS libraries and “AJAX” interactions fit in, IMHO.

Bottom line: JS/AJAX stuff, yes but only if it’s done right, which
means accessible and done in a context of progressive enhancement.

What do you guys think?
--
Antonio

About me: I’ve been hacking with Django for some weeks now, I’ve
been developing websites for almost 8 years now and I used to code in
PHP/JS/ActionScript/XSLT. I’ve been moving to Python for the last
year and a half and Django was a godsend in that regard. My first and
only contribution to the project so far has been this rather outdated
guide to get Django on OS X:

http://cavedoni.com/2005/django-osx

I had also planned to contribute the code to produce Atom feeds from
the syndication framework, but somebody beat me to it by a couple of
days (damn!).

[Christopher Lenz]

Post by Antonio Cavedoni

Post by Christopher Lenz
While there are definitely many types of validations that can't be
performed on the client side, calling back to the server just to
check whether e.g. a text-input is empty is overkill IMO. The same
goes for validity checks for common things like text fields
expecting an email address or date.
I'd prefer a hybrid approach, where simple javascript validation
checks are generated, and the others are performed via AJAX
callbacks.

I don’t agree with this approach. While I think client-side
validation is fine and dandy, and from a user perspective is
definitely the way to go, we cannot rely on it.

Well, it goes without saying that server-side validation is *always*
required. AJAX or not.

Post by Antonio Cavedoni
email-validation in JS on the client and email-validation on the
server (yes, I’m oversimplifying, but you get the idea).

I don't agree, at least for the common cases such as validating
emails, URLs, date/time fields etc. It really shouldn't be necessary
to call back to the server for trivial and/or common validation tasks.

Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/

[Simon Willison]

Post by Christopher Lenz
I don't agree, at least for the common cases such as validating
emails, URLs, date/time fields etc. It really shouldn't be
necessary to call back to the server for trivial and/or common
validation tasks.

I don't understand why not. It's hardly a performance burden (the
amount of data being transferred is trivial) and it makes things on
the client incredibly simple as the validation logic for one field
(send to the server, see what it says) is reusable for every other
field. Premature optimisation is the root of all evil.

If I get some spare time soon I think I'll build the Ajax-only
validation thing as a proof of concept. I'm willing to bet that the
performance difference between it and pure client-side validation
will be imperceptible in most cases. If it's noticable and obvious
that the user experience would be better with hybrid client-side/Ajax
validation then I'll throw my support firmly behind that option.

[hugo]

Post by Simon Willison
If I get some spare time soon I think I'll build the Ajax-only
validation thing as a proof of concept. I'm willing to bet that the
performance difference between it and pure client-side validation
will be imperceptible in most cases. If it's noticable and obvious
that the user experience would be better with hybrid client-side/Ajax
validation then I'll throw my support firmly behind that option.

Please not AJAX-only - we do still want to validate on POST, too, as
the user might just have JavaScript disabled or is using IE with
settings that don't allow the XmlHttpRequest object ...

But AJAX validation callbacks done as asynchronous requests that just
trigger some "colour this red" logic won't really be a big burdon on
performance - since they happen asynchronously. But you need to keep
them fast and short enough to make sure that you don't run out of
threads - most browsers set some upper limit of how many requests can
run in parallel, and XHR shared that numbe of threads ...

bye, Georg

[Simon Willison]

Post by hugo
Please not AJAX-only - we do still want to validate on POST, too, as
the user might just have JavaScript disabled or is using IE with
settings that don't allow the XmlHttpRequest object ...

That should go without saying - server-side validation will always be
the priority as it's essential for application security in addition
to providing decent degradation.

Cheers,

Simon

[Eugene Lazutkin]

There is a well know effect related to the light speed limit. :-) Basically
it adds some constant delay to all packets. This delay depends on physical
wire distance between client and server. Even if you have infinite
bandwidth, you will still experience delay. Retransmissions of packets and
technical delays (e.g., waiting for ACQ) will compound it. (The latter one
explains the speed difference between TCP and UDP packets.) That's why it is
better to reduce number of communications between hosts to reasonable
minimum. It reduces server load and network load, while improving
responsiveness of user interactions. It's a must for some network
implementation, e.g., satellite-based networks.

Obviously if hosts have limited bandwidth, it will introduce more delays.

While it is possible to ignore this delay for specific applications, it's
not a good assumption for all applications possible with Django.

Thanks,

Eugene

I don't agree, at least for the common cases such as validating emails,
URLs, date/time fields etc. It really shouldn't be necessary to call
back to the server for trivial and/or common validation tasks.

I don't understand why not. It's hardly a performance burden (the amount
of data being transferred is trivial) and it makes things on the client
incredibly simple as the validation logic for one field (send to the
server, see what it says) is reusable for every other field. Premature
optimisation is the root of all evil.
If I get some spare time soon I think I'll build the Ajax-only validation
thing as a proof of concept. I'm willing to bet that the performance
difference between it and pure client-side validation will be
imperceptible in most cases. If it's noticable and obvious that the user
experience would be better with hybrid client-side/Ajax validation then
I'll throw my support firmly behind that option.

[Eugene Lazutkin]

There is a well know effect related to the light speed limit. :-) Basically
it adds some constant delay to all packets. This delay depends on physical
wire distance between client and server. Even if you have infinite
bandwidth, you will still experience delay. Retransmissions of packets and
technical delays (e.g., waiting for ACQ) will compound it. (The latter one
explains the speed difference between TCP and UDP packets.) That's why it is
better to reduce number of communications between hosts to reasonable
minimum. It reduces server load and network load, while improving
responsiveness of user interactions. It's a must for some network
implementation, e.g., satellite-based networks.

Obviously if hosts have limited bandwidth, it will introduce more delays.

While it is possible to ignore this delay for specific applications, it's
not a good assumption for all applications possible with Django.

Thanks,

Eugene

I don't agree, at least for the common cases such as validating emails,
URLs, date/time fields etc. It really shouldn't be necessary to call
back to the server for trivial and/or common validation tasks.

I don't understand why not. It's hardly a performance burden (the amount
of data being transferred is trivial) and it makes things on the client
incredibly simple as the validation logic for one field (send to the
server, see what it says) is reusable for every other field. Premature
optimisation is the root of all evil.
If I get some spare time soon I think I'll build the Ajax-only validation
thing as a proof of concept. I'm willing to bet that the performance
difference between it and pure client-side validation will be
imperceptible in most cases. If it's noticable and obvious that the user
experience would be better with hybrid client-side/Ajax validation then
I'll throw my support firmly behind that option.

[Robert Wittams]

Post by Simon Willison

Post by Christopher Lenz
I don't agree, at least for the common cases such as validating
emails, URLs, date/time fields etc. It really shouldn't be necessary
to call back to the server for trivial and/or common validation tasks.

I don't understand why not. It's hardly a performance burden (the
amount of data being transferred is trivial) and it makes things on the
client incredibly simple as the validation logic for one field (send to
the server, see what it says) is reusable for every other field.
Premature optimisation is the root of all evil.
If I get some spare time soon I think I'll build the Ajax-only
validation thing as a proof of concept. I'm willing to bet that the
performance difference between it and pure client-side validation will
be imperceptible in most cases. If it's noticable and obvious that the
user experience would be better with hybrid client-side/Ajax validation
then I'll throw my support firmly behind that option.

It would be pretty easy to use AJAX by default, and client side stuff as
an alternative, eg

@client_side('path/to/script', 'js_function')
def my_validator(args):
.....

def client_side(path, func_name):
def _dec(func):
func.js_path = path
func.js_func_name = func_name
return func
return dec

And then whatever bit of code generates the javascript for the ajax can
utilise these function attributes.

So everything works via AJAX by default, but people can easily add in
client side overrides.

But of course if there is no point in doing this performance wise, we
shouldn't bother.

---
Usual "We all know how to use decorators in python <2.4" disclaimers apply.

[Eugene Lazutkin]

Inline.

along with it. We're in 2005, and we *know* that some people turn JS off
on purpose, use browsers where JS support sucks, or are disabled

I specifically track js settings of all people who come to my site
(http://lazutkin.com/). So far I saw a handful of real people disabling js.
JavaScript was enabled on more than 99.99% of browsers. Majority of browsers
are recent with decent support of js. Browsers constituted 92.3% of my site
traffic (incomplete 2005 data):

70% FF + Mozilla
13.1% IE
4.3% Safari
2.9% Opera
1.2% Konqueror
0.3% Camino
0.2% Netscape
0.2% Galeon
0.1% Nokia browser

The rest (7.7%) are bots, wget, and RSS readers. Of course my site is not a
representation of the whole www (wwww?) but a random sample. But it matters
to me. :-) Up to this year I managed public consumer-oriented web apps with
big traffic and saw practically similar picture with IE and FF swapped.

There are two real problems:

1) Mobile users (PDAs, cell phones).
2) Visually-impaired people.

They both have problems with dynamic web sites.

(You can add one more for US-based web sites: non-English speaking users.
These users require special content too. But it is a different category.)

Both categories are a small minority of visitors. It doesn't mean they
should be neglected, but majority of users should not suffer from
limitations imposed by catering to minority users. In practice the best
solution is to separate content for different target audiences. That way you
can provide the best user experience for everybody. That is why major web
sites have separate sections for mobile users, Spanish language sections,
and text-only pages to accommodate screen readers.

I don't see dynamic web pages as alarming trend. Then again I didn't hear
people complaining about interactive desktop applications, say games, which
don't run on your mobile, do not have Spanish language content, and
impossible to play by disabled people.

Talking specifically about Django:

1) It should be able to produce web pages, which don't use dynamic features.
2) It should be able to support formats other than HTML.
3) It should be able to produce web pages in different languages.

I think Django does all of them. The rest is up to web site designers.

Thanks,

Eugene

[Robert Wittams]

Post by David Ascher
Goofy idea: use the Python logic to generate JS code to do clientside
validation based on the model-specified constraints. Detailed specification
and implementation are left as an exercise to the reader. ;-)

Scarily:

http://codespeak.net/svn/pypy/dist/pypy/translator/js/

PyPy rpython -> js translator, then run the full PyPy on that. Overkill,
perchance ;-)

Even worse:

http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework

Translates in a sickeningly stringish fashion python to javascript.