Inline. "James Bennett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: >> I don't recall anybody proposing "AJAX in the core". >I've seen it asked for more than once, particularly in the IRC >channel. People ask for Django to pick one AJAX library and integrate >it. To me, that's "AJAX in the core". 1) Let's keep different forums separate. I hope you responded to those unnamed guys in the IRC channel. 2) My car has an integrated CD-player. Does it mean it is "in the core"? I respectfully disagree with your definition of "in the core" as mere "integrated". >> While Ajax is generating a lot of buzz lately causing adverse reaction in >> non-marketing >> people, don't overlook it is potential to improve usability of web sites. >I don't feel that I am; I do feel that right now the vast majority of >people who are clamoring for AJAX are woefully uninformed about what >it is, what it does, and how best to use it. As a result, it ends up >not being used to enhance usability, but rather to provide lots of >flashy effects and transitions which may well have a negative impact >on overall usability -- many people are rushing to "AJAX-ify" their >applications without doing any sort of thinking about usability at >all, let alone testing to determine the impact. This is a good argument against everything from cars to iPods. People can (and will!!!) abuse everything. If usability requires "flashy", let's do "flashy". I don't care how people would abuse it if it solves some real problems. Just for the record: in my book "flashy" == "bad usability" in 99.99%. >Which, again, says to me that the best thing for Django is to let all >those people be Some Other Framework's Problem. >> As any indication of that you can look at requests in this list and in >> Django-User for reuse of parts of Admin in their own applications. People >> don't want to reinvent the wheel, they want to reuse the wheel. Same goes >> for Ajax. >Integrating AJAX into Django would mean settling on one toolkit to use >for AJAX effects, and building around that. This is inconsistent with >how Django handles other things, because for the most part Django is >agnostic about what tools you use; for example, if you don't like the >template system, you can use another. But this sort of flexibility >isn't easy (or, sometimes, even possible) to maintain with AJAX >toolkits. I would be happy, if Django supports many libraries, but I don't think we can afford it. E.g., I can understand the need for 2 versions of Admin: plain vanilla HTML, and Ajax version. If somebody wants to create 3rd version of Admin, it is fine with me, but it looks like an overkill. Basically all this Ajax thingy boils down to three different things: 1) Callbacks, when Django sends objects to the client. It is about the eternal question: "how to expose server-side stuff to client side". It is pretty much library-agnostic. One possibility is to add a special form of Response object, which will serialize returned object in JSON (IMHO, preferred way) or XML format. We may need to mark statically (similar to META options), which fields of the model should not be serialized. Additionally, it makes sense to provide some simple dynamic filtering of object's fields before serialization. 2) A front end for manipulation of server-side objects from client-side script. This is an opposite to callbacks: client sends objects to Django. Django already provides unified methods for model objects (tutorials cover most of them, details can be found here: http://www.djangoproject.com/documentation/db_api/ and http://www.djangoproject.com/documentation/models/). You can create/modify/delete objects, retrieve related objects, search, and so on using command line. It is quite simple to provide an automated support for some safe subset of it using JSON/XML as input. This should be an optional feature. Some field markup may be required. 3) Ready-to-use client-side components, which do GUI simple and ergonomic. >From the top of my head: client-side replication of a field group to associate multiple subobjects with a master object; type-ahead style of object selector; rich edit (it is partially solved by 3rd party editors); drag'n'drop support for complex selections; menu widgets; client-side form validation; and so on. #1 and #2 should be rich enough to provide an adequate support for such components. Notes: - #1 and #2 do not require to settle for one library. They require to settle for APIs and formats. - People may like to have more than one implementation of #3 but I doubt it. It should be possible for advanced users to implement their own custom GUI using #1 and #2 and whatever Ajax library they desire to use in their own custom application. - Please note that "flashy effects and transitions" are not mentioned. :-) If people want to implement "dancing words" or similar distraction, let them do it. It is not up to us to police them, but it is up to us to support only reasonable components. Thanks, Eugene PS: In any case it makes sense to study the only existing Django Ajax implementation: http://opensvn.csie.org/django_ajax/trunk/. You can see what was done right, and what is wrong.
