Re: Django Ajax Redux

On 12/12/05 01:15, Lachlan Cannon wrote: Using classes it's not clear if it's there to style an element or to pass params to some js widget or whatever. When using custom attrs it's much clearer what's going on. I couldn't disagree more. :) class is there to 'subclass' elements. The W3C them

Re: Django Ajax Redux

"Robert Wittams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > I think #925 is very important. A 'component' effectively becomes a > template-tag + a processor. This can be used to create a 'component' > generic view for partial page updates. Needs more thought (preserving > oth

Re: Django Ajax Redux

Using classes it's not clear if it's there to style an element or to pass params to some js widget or whatever. When using custom attrs it's much clearer what's going on. I couldn't disagree more. :) class is there to 'subclass' elements. The W3C themselves say

Re: Django Ajax Redux

On 12/10/05 21:45, Eugene Lazutkin wrote: Inline. "Robert Wittams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] I had a look at dojo before and these were the questions that popped up in my mind: Dojo seems to rely on adding its own unnamespaced attributes to normal elements.

Re: Django Ajax Redux

 :-) If you throw in the latest Opera and the latest Konqueror in the mix you covered 99.95% of the real world browser market. The rest is going to be Win95, lynx, and w3x.   Thanks,   Eugene "David Ascher" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]...On 12/10/05, hug

Re: Django Ajax Redux

Alex Russell wrote: > Therefore, if you actually care about validation, you can namespace > things to your heart's content. That sounds really good. So it seems like we could just output it either way according to a project wide setting, and default to the mechanism that works with IE. Cheers,

Re: Django Ajax Redux

BTW, there are problems with any XHTML solution, which uses any JavaScript. A lot of stuff should be done differently. Given all uproar with W3C vs. WHATWG, and the current state of XHTML affairs, I would not mess with XHTML just yet. Let's see how it will turn out. Thanks, Eugene "James Be

Re: Django Ajax Redux

e compressor, > and something to complain if this hasn't been done? I think we need to do our own profile depending on what we need/have. I don't think we need to maintain a live version of Dojo. I prefer to freeze the code between Django Ajax versions. > Use this to create th

Re: Django Ajax Redux

"Robert Wittams" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > So I think Dojo could do all of this, at the cost of adopting its heavy > widget framework. MochiKit could also do most of this with the addition > of Drag and Drop and some simple visual effects. I believe there are

Re: Django Ajax Redux

"Colin Howlett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > If as Eugene says, we're not interested really in visual effects, then > perhaps we should choose something smaller, like prototype.js or > tw-sack.js (just 4 lines of js to retrieve an html fragment from a URL > and

Re: Django Ajax Redux

Inline. "hugo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Just some thoughts from me on this: it would make much more sense to > address the whole Ajax stuff from a practical point - start adding > stuff to the admin that needs Ajax or at least makes good use of it. > Then w

Re: Django Ajax Redux

Regardless of the pros and cons of particular javascript frameworks, which we could argue about forever - we need to address Eugene's proposal. I would like to see what usage of his proposal in a template would look like - that seems to me to be the most important thing. Fundamentally, I'm with

Re: Django Ajax Redux

hugo wrote: > >Dojo seems to rely on adding its own unnamespaced attributes to normal > >elements. Is this compatible with strict use of XHTML? > > That would be my biggest technical gripe (beside the missing > documentation) with Dojo - (X)HTML with invented unnamespaced tags > will not validate

Re: Django Ajax Redux

Dojo does not for you to do anything that doesn't validate. We support direct, non-namespaced attribute setting in addition to namespaced attributes and tags. Support for the non-namespaced variants is considered useful by the Dojo community but isn't something you have to adopt. Wether browsers

Re: Django Ajax Redux

Hi Robert, I'm Alex Russell, Project Lead for Dojo. Dojo does *not* require the use of unnamespaced attributes to normal elements. Dojo uses a parser system which normalizes between namespaced elements and attributes, non-namespaced elements and attributes, and any combination thereof, even in n

Re: Django Ajax Redux

>thread, but I want to point out that while I agree that a non-JS fallback is >a reasonable requirement for the Django Admin, I don't believe that a non-JS >fallback is necessarily a requirement that needs to be imposed on an "AJAX" >integration strategy. In other words, for a lot of us, the admi

Re: Django Ajax Redux

On 12/10/05, hugo <[EMAIL PROTECTED]> wrote:  Oh, and please keep in mind that there should be at least a sensiblefallback solution for those who don't want to (or plain and simplecan't) use _javascript_ all the time.I want to read more about the concrete proposal before I dig deep into this thread

Re: Django Ajax Redux

>Dojo seems to rely on adding its own unnamespaced attributes to normal >elements. Is this compatible with strict use of XHTML? That would be my biggest technical gripe (beside the missing documentation) with Dojo - (X)HTML with invented unnamespaced tags will not validate any more, and if there

Re: Django Ajax Redux

>But are we sure we want to build our own javascript framework from >scratch? Of course not, that would be rather silly. It's just much easier to decide what framework to use if you actually worked with them and solved problems with them. From my current point of view I would choose MochiKit over

Re: Django Ajax Redux

The other two come down to: * Mochikit - well documented and architected, compact but missing features. * Dojo - almost undocumented, reportedly well architected, huge (but configurable). Lots of features. I am not going to pretend to have an authoritative opinion here but I was looking at

Re: Django Ajax Redux

I think ticket 13 is a great place to start with all of this. This is the most critical need in the admin for Ajax (I could live the rest of my life without without live search). I can write the HTML/CSS for my mockups, but it will be up to somebody else to write the JS.

Re: Django Ajax Redux

On 12/10/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > Dojo seems to rely on adding its own unnamespaced attributes to normal > elements. Is this compatible with strict use of XHTML? No, it's not; this would result in a yellow screen of death if a page were served as application/xhtml+xml. Also

Re: Django Ajax Redux

I had a look at dojo before and these were the questions that popped up in my mind: Dojo seems to rely on adding its own unnamespaced attributes to normal elements. Is this compatible with strict use of XHTML? What would the mechanism for fallbacks be? To produce the non-JS case, then use unobtr

Re: Django Ajax Redux

Ok. We had this exact same discussion before, and we did come to the conclusion (I think) that it would be better to reuse something than iterate through IEs bug list ourselves. The two choices seriously considered were Mochikit and Dojo. prototype was pretty much excluded as it is apparently of f

Re: Django Ajax Redux

Hmmm, obviously, when I say " We clearly have the talent and the focus to do a good job" I don't mean to take credit for the wonderful work of others, or to imply that Eugene does not have the talent or focus to do a good job with this. After all, I'm just a noob who hasn't contributed anything

Re: Django Ajax Redux

Georg, I agree with you that we should approach this issue by building just what we need in a practical and incremental way, so +1 for that. But are we sure we want to build our own javascript framework from scratch? There are two opposing forces here: the effort to develop and maintain our ow

Re: Django Ajax Redux

On 10 Dec 2005, at 13:49, hugo wrote: Let's try something different and first provide problem solutions, and _then_ extract a framework out of them. +1 Afternoon, man about the Internet -- http://aftnn.org/

Re: Django Ajax Redux

>Basically I >want to propose an implementation. At least I'll collect your thoughts, >criticism, corrections, and, hopefully, blessings. Just some thoughts from me on this: it would make much more sense to address the whole Ajax stuff from a practical point - start adding stuff to the admin that

Django Ajax Redux

t in the wiki in its present form. The size of this proposal is not conductive to mail list posting. Please read it here: http://lazutkin.com/blog/2005/dec/10/django-ajax-redux/ Thanks, Eugene

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Inline. "Maniac" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > separation. This is bad (allow me not to descend into an academic-style > discussion why). I am with you. > What I was trying to say is that I'm agains 'Ajax support' only if it > means what I described above -

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Eugene Lazutkin wrote: Care to share these reasons or provide a link to reasons you support? Unfortunately all this client-server separation is a marriage of convenience, which is mostly created by network speed. Trust me: as network speed grows, client-server separation will be less defined.

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Inline. "Baishampayan Ghose" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Heh, AJAX, as you might have noticed is mostly all buzzword crap, but No. My experience is quite opposite: AJAX is very useful tool. Not more, not less. > again many not-so-knowledgeable developers wo

Re: Django/Ajax (Re: Small report from Django/Rails meetup)

I pulled some of the info from this thread and started a Wiki page: http://code.djangoproject.com/wiki/AJAX Please commence filling in the blanks and correcting my errors and misrepresentations :)

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Baishampayan Ghose wrote: > Yeah surely. I have discussed about this AJAX stuff at length on IRC and > my preference is shared by a lot of people and has been posted on the > list too. What I feel is that I know Django ``supports'' AJAX today > itself in a way that it doesn't restrict / stop the u

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

#x27;s world ;) [snip] > 4) Let's return to the topic and discuss it in constructive manner. While > you chided me I actually tried it (see my other post). Yeah, but that was in a different thread, and I thought it was good to stop THIS thread. > 5) I would be honored if you share you p

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

James Bennett wrote: > For example, Rails includes an "AJAX library" called Prototype; this > library provides "AJAX" functionality in that it delivers a facility > for making asynchronous server calls from the client via JavaScript, > but it also provides a number of easily-used visual DHTML eff

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

hided me I actually tried it (see my other post). 5) I would be honored if you share you position with us on Django Ajax. I noticed that you voted +1 for Ajax in Django 1.0 --- I am sure you have something interesting to say on this topic, if you feel so strongly for it. Thanks, Eugene PS: I di

Django/Ajax (Re: Small report from Django/Rails meetup)

Today I discovered that I missed very interesting Django/Ajax-related discussion on #django. Specifically MochiKit-Dojo comparison was discussed. I know it is hard to talk about Dojo, when documentation is lacking. Let me present my take, based on some experience with both toolkits from

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

>Remote scripting's been around, but GMaps and Garrett's >article >whacked the mainstream designers over the head. AJAX >can stand for >whatever acronym you want. When designers say "AJAX", >they mean rich >interaction and a broken page request/response model >broken. Actually AJAX can be done

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: > > Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But > "AJAX effects" == visual effects? You have to publish your own dictionary, There's a disconnect between the code monkeys and the designers. Remote scripting's bee

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eugene, [snip] >>For example, Rails includes an "AJAX library" called Prototype; this >>library provides "AJAX" functionality in that it delivers a facility >>for making asynchronous server calls from the client via JavaScript, >>but it also provides

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Inline. "James Bennett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >Many so-called "AJAX libraries" are as heavy on the "visual DHTML "So-called" by whom? >For example, Rails includes an "AJAX library" called Prototype; this >library provides "AJAX" functionality in that it

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: > Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But > "AJAX effects" == visual effects? Many so-called "AJAX libraries" are as heavy on the "visual DHTML effects for use with AJAX" as on the actual meat of "AJAX" itself

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But "AJAX effects" == visual effects? You have to publish your own dictionary, man. Could you be more specific about drag-and-drop being a visual effect? I was always thinking that it is much much more than that --- a functiona

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > What problem does this actually solve? Why do you care that people would > use a bundled JS library? Should we also excise the template system from > Django to avoid offending Kid? The ORM to avoid offending SQL object? > What would be left?

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote: > What are these mysterious "AJAX effects" you talking about in your posts? Is > it the same as "AJAX in the core" or different beast? As I mentioned in an earlier message, many "AJAX libraries" provide a large stable of DHTML components whi

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

What are these mysterious "AJAX effects" you talking about in your posts? Is it the same as "AJAX in the core" or different beast? Thanks, Eugene "James Bennett" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 11/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote: > What probl

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

hugo wrote: > Hi, > > >>So lets not pretend that there is zero cost to *not* picking something. >>Users don't like uncertainty. > > > I just don't see "bundle a JS library with Django" as anything that > could be described as "add AJAX support to Django". Yes, we can argue over terminology al

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

James Bennett wrote: > As for the related topic of AJAX in the admin, I think the problem of > "Django bundles an AJAX library, I should use that one" can be avoided > with some care in how AJAX is used within Django; if only a particular > subset of functions is needed, it may be possible to bund

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Hi, >So lets not pretend that there is zero cost to *not* picking something. >Users don't like uncertainty. I just don't see "bundle a JS library with Django" as anything that could be described as "add AJAX support to Django". Sure, we can bundle to our hearts content - and if there will be AJA

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/14/05, hugo <[EMAIL PROTECTED]> wrote: > Actually the only thing I can think of that would be good if django had > it, would be a REST style API to access model stuff that automatically > will be returned in JSON format. That would allow JavaScript code to do > easy database queries without

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

...and of course typically there is a limit on how many items to be returned for auto-suggest, but taking it into considiration ruins all fun of arguments. :-) "Jeremy Dunck" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On 11/14/05, Maniac <[EMAIL PROTECTED]> wrote: > But I th

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On 11/14/05, Maniac <[EMAIL PROTECTED]> wrote: > But I think this whole approach is wrong and should not be supported. > There are certain reasons behind separating server and client part and > wishing to break this barrier smells like a bad design to me. If Django > will make such things easy the

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

"Maniac" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > But I think this whole approach is wrong and should not be supported. > There are certain reasons behind separating server and client part and Care to share these reasons or provide a link to reasons you support? Unfortun

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

hugo wrote: > Hi, > > >>Hence, I plead with the proponents of "Ajax support:" Please >show >>concrete examples of what you want. Enlighten us. > > > Actually the only thing I can think of that would be good if django had > it, would be a REST style API to access model stuff that automatically

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Adrian Holovaty wrote: I've been using XMLHttpRequest for years now. My chicagocrime.org site, powered by Django, uses Ajax in several places (chicagocrime.org/map, for one). Django made this very easy. Yet I still can't fathom what "Ajax support" at the server-side-framework level *means*.

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

Hi, >Hence, I plead with the proponents of "Ajax support:" Please >show >concrete examples of what you want. Enlighten us. Actually the only thing I can think of that would be good if django had it, would be a REST style API to access model stuff that automatically will be returned in JSON forma

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

"Adrian Holovaty" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >With that in mind, I still want to comprehend this mysterious concept >of "Ajax support." In fact, I yearn for it. I want to know what it is, >desparately. Let me take a stub at it. 1) Client-side form validation. 2

Re: Django Ajax (WAS: Re: Small report from Django/Rails meetup)

On Nov 14, 2005, at 4:34 PM, Adrian Holovaty wrote: This is a good conversation, and I hope it continues. Like ships passing in the night... :) Jacob

Django Ajax (WAS: Re: Small report from Django/Rails meetup)

This is a good conversation, and I hope it continues. Here are some thoughts, which I've brought up a number of times over the past couple of months and remain unresolved. Django is all about *actual tools that get actual stuff done* -- not about buzz words, or academic noodling, or "let's make

django + ajax

does django is going to integrate ajax in a near future? I think that mochikit is a good option