|
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
Here
are my half cooked thought on the issue.
On 11/18/05, Wilson Miner <[EMAIL PROTECTED] > 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
+91-9867-359-701
|
