On 11/18/05, Wilson Miner <[EMAIL PROTECTED] > wrote:
I think we should be as toolkit-agnostic as we aretemplatesystem-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.
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
+91-9867-359-701
