Re: Django and AJAX: Setting aside the conflict

[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/_javascript_Helper.html). It uses prototype.js. Visual features require inclusion of script.aculo.us. Following high-level features are covered: 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. Asynchronous submission of regular forms. Observation of fields/forms: trigger a callback, when field/form was changed by user. 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: 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. 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/.) 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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... On 11/16/05, Robert Wittams <[EMAIL PROTECTED]> 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