The following patch allows you to subclass AnonymousUser and get a free
__repr__() in the new class:
diff -Nru django_svn/django/parts/auth/anonymoususers.py
mydjango/django/parts/auth/anonymoususers.py
--- django_svn/django/parts/auth/anonymoususers.py 2005-12-10
18:10:13.0 -0500
++
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.
:-) 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
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,
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
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. Is this compatible with strict use
"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
"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
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
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
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
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
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
>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
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
>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
>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
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
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.
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
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
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
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
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
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/
>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
Three weeks ago we had a discussion about Ajax support in Django, which
resulted in "Ajax and Django" wiki page. A short recap: it lists a vague
goal, some general considerations, and possible strategies; it scratches the
surface of existing implementations (mostly RoR), existing third-party
t
>Three bugs were fixed in the Chinese Simplified po file - the following
>three messages should not be translated:
Thanks for the update, I added them to the repository. For future
updates: just post a ticket to the Django ticket system and attach the
.po file there. No need to attach the .mo fil
28 matches
Mail list logo
