Eugene Lazutkin wrote:
Look at Dojo. I did a small how-to on creating widgets here:
http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who
read it, missed my point: it was not about Ajax functionality (you can
do it with any library), it was about creation of self-contained generic
widgets, which don't pollute your html code with unnecessary garbage.
You can download LiveFilter.js (link in the tutorial) and use it
literally without modifications with practically any form in your
project to make it "live". All you have to do is to implement a
relatively simple view to support it on Django's side (example
included). No JavaScript knowledge is involved in actual use. But if you
want to be fancy, you can create your own widgets, and reuse them across
projects. Additional bonus (useful for medium-to-large projects): such
widgets provide a clean separation between client-side programmers,
server-side programmers, and (most importantly) designers --- everybody
is doing stuff they are familiar with.
Nice example. I think it points towards the basic direction that a
Django AJAX framework should take. Client-side code should be in
template-vars (ContextProcessor if needed) and template-tags connected
to client-side "views" in .js files. Server-side code should consist of
simple RESTful views (there are several existing generic views that
could easily be used for that task, and there are probably some good
ideas out there for other good AJAX-friendly generic views).
I think it points to another idea I think would be nice to see in
Django: "smart views" (actually, it would really just be a smart
template loader and a single additional piece of information needed to
pass to the generic views, in order to pass to the template loader).
There are several cases where you might have the same view (all of the X
objects, details of the X object with id=somenumber, ...), but different
output formats based on circumstance. You could let the template loader
handle the format... I would use the file extension. For example, you
could have your HTML templates as myobject_list.html and your RSS
template for the same object as myobject_list.rss. Then you could just
add the proper format setting to your info_dict for the generic
object_list view and let it choose the proper one. (Assuming for
whatever reason you don't want to use the existing RSS Framework, which
works well, but this is just the first example to come to mind.)
Another example would then be the "simple" views for use in AJAX/REST
projects (using .ajax or .rest or .js or .raw.xml depending on the
content type, perhaps).
You could even design your URLs to take advantage of the format context
*if you wanted*. Something like (using an object_detail-style example
this time):
``r'^mysite/coolthings/(?P<object_id>\d+)(?P<output_format>\.\w+)?/?'``
That would match things like:
/mysite/coolthings/1/ (The typical HTML view for a Django site)
/mysite/coolthings/1.xml
Overall it would be subtle "opt-in" and shouldn't affect the current
behavior (ie, if the generic view+template loader doesn't know the
expected output format, default gracefully to the default in settings.py).
Anyone else see it as useful?
--
--Max Battcher--
http://www.worldmaker.net/
"History bleeds for tomorrow / for us to realize and never more follow
blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
