On 7/11/06, Bill de hÓra <[EMAIL PROTECTED]> wrote:
> I need to test this properly and fill in the mappings, but the gist of
> the approach should be clear. When that's done, unless someone has an
> objection, I'll file a patch against
The structure and logic look good; my only worry is that this
On 7/11/06, Iain Duncan <[EMAIL PROTECTED]> wrote:
> If need be, I don't mind working on my own hack of the delete function
> for the admin interface for now. My questions:
Patches would be gratefully reviewed.
> Is there are news on how this issue is likely to be handled?
Not that I'm aware of
Bill de hÓra wrote:
> I need to test this properly and fill in the mappings
The official Cyrillic-Latin mapping could be found here:
http://en.wikipedia.org/wiki/Translit
It could be like this:
var RUSSIAN_MAP =
{
"а": "a","к": "k","х": "kh,
"б": "b","л": "l","ц": "ts",
"в": "v"
On Tue, 2006-07-11 at 21:34 -0700, Gary Wilson wrote:
> Thinking of this some more, I'm wondering about the names is_logged_in
> or is_authenticated. They could be a little misleading since they
> aren't really checking if the user is logged in or not. One might be
> led to believe that they cou
Thinking of this some more, I'm wondering about the names is_logged_in
or is_authenticated. They could be a little misleading since they
aren't really checking if the user is logged in or not. One might be
led to believe that they could do something like logged_in_users =
[user.is_logged_in() fo
I like it too.
To attone for my duplicate thread, I have created a ticket and patch
for this.
http://code.djangoproject.com/ticket/2332
I'm not sure how you "declare is_anonymous as depreciated", Malcom so
I'll leave that to you ;)
--~--~-~--~~~---~--~~
You rece
Replying to myself again...
Hacking away at things a bit more, I can see so far only one serious
problem with the implementation outlined above. Moving the connection
information to model._default_manager.db is going to require changes in
django.db.query, specifically in QuerySet._get_sql_clause
On Wed, 2006-07-12 at 02:54 +0100, Bill de hÓra wrote:
> Malcolm Tredinnick wrote:
>
> > Personally, I was kind of hoping whoever wrote
> > the patch might think this sort of thing through and give us a concrete
> > target to throw ideas at. :-)
>
> Hi Malcolm,
>
> Here we go:
aah ... batter u
Malcolm Tredinnick wrote:
> Personally, I was kind of hoping whoever wrote
> the patch might think this sort of thing through and give us a concrete
> target to throw ideas at. :-)
Hi Malcolm,
Here we go:
[[[urlify.js:
var LATIN_MAP =
{
'À':'A',
'Á':'A',
'à':
déjà vu
http://groups.google.com/group/django-developers/browse_thread/thread/2cc178fe7c8c9046/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
On Tue, 2006-07-11 at 15:52 -0700, SmileyChris wrote:
> When using templates and the user interface, the logic seems backwards
> to check for an anonymous user as opposed to a logged in user.
>
> By using user.is_anonymous in a template, you assume that if it's false
> then the user is logged in,
I asked about this on the user list and was told it has been noticed as
an issue, but in the meantime, I need to find a way to make sure that in
the admin interface related entries ( through tables connected by a
foreign key ) do not get automatically deleted, but rather have the
foreign key in qu
When using templates and the user interface, the logic seems backwards
to check for an anonymous user as opposed to a logged in user.
By using user.is_anonymous in a template, you assume that if it's false
then the user is logged in, where in actual fact "user" may just not be
getting passed to c
> OK, thoughts, anyone?
When i first heard of multi-db i more thought about support for
clustering then moving some apps/models to other databases, which is
great, too of course.
for example: having one master db and some slave dbs that mirror the
master db. requests should go to slaves in some
Replying to myself... here's what I've come up with to explain the
problems I see in my current implementation and what I think should be
done to fix them. Apologies in advance -- it's quite long.
I've implemented a bit of this just to make sure it would work, mainly
the basic parts in django.db.
Hi,
Django's check for internal/external links (via the HTTP_REFERER header)
is pretty naïve, and it means I'm currently getting tons of e-mails
telling me I have broken *internal* links, when actually they are
external links from Google's cache, which happens to contain the
domain in the re
Hi,
Generic views set messages, but don't enable translation, such as:
if not request.user.is_anonymous():
request.user.message_set.create(message="The %s was updated
successfully." % model._meta.verbose_name)
This is only an example, there are other similar cases.
Shouldn't this get transla
Hi!
Is there a page about these plans on the wiki? I'm interested in
seeing how this will change since I currently have around 300+ lines
of custom manipulators code in a single project. Of course I'm also
interested in seeing if I can help in any way.
Thanks!
Jorge
On 7/11/06, favo <[EMAIL P
Hi,
I propose to add a setting that makes cookies 'secure'.
The secure flag tells the browser to send this cookie only over
https. The idea is that https makes sure that the cookie does not
leak out to a domain that belongs to someone else, even when the
DNS has been tampered.
Since the authent
[snip most of OTHER_DATABASES proposal]
> * ``MODELS`` is a list. Each item in the list may be:
>
> * ``app_label.module_name`` if a single model should be use this
> connection.
> * ``app_label`` if the entire app should use this connection
>
> How does this sound?
Good enough for
> What about making Manager callable? It could take a database
> identifier, or even an object with connection info, and return a new
> Manager instance with the specified database info. This would let you
> keep using Model.objects with a default database, or for the case where
> multiple databas
On Jul 11, 2006, at 8:08 AM, jason pellerin wrote:
> Here's another case that I'd like to see handled gracefully, that I
> think can be handled better with your proposed syntax than mine: one
> app with many models, some of which use a named connection. To me, the
> ideal way to handle that would
Hope new manipulator replacement is flexible and with some back
backward compatible. we have many funcition based on custom
manipulator(form ) or automatic ones.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Djan
A wrinkle occurred to me last night that I really should have thought
of earlier, and that calls into question my whole connection-handling
setup.
When served as a WSGI app in a container like Paste, settings can be
different on every request. That means, first off, that however we
decide to stru
> It looks okay and you are protecting with a conditional test that checks
> for the right attribute being present. What problems are you seeing?
> It's pretty easy to get into a knot in the __new__() method there, but
> from the fragment you posted you seem to have avoided the obvious
> problems
Hi
I have an application which when the user is logged in translates
using:
request.session['django_language']='en-uk' or what ever language
code they select.
This works fine when the user is logged in but I'd like to offer the
user the option to translate the "welcome" screen. I've done th
On Tue, 2006-07-11 at 03:15 -0700, Bjørn Stabell wrote:
> Adrian Holovaty wrote:
> > You're right -- models will gain validation, and there will be a
> > helper function/method that returns a data structure that encapsulates
> > form validation/redisplay (like a Manipulator currently does). That'l
Adrian Holovaty wrote:
> You're right -- models will gain validation, and there will be a
> helper function/method that returns a data structure that encapsulates
> form validation/redisplay (like a Manipulator currently does). That'll
> be replacing the current "automatic" manipulators, which I'v
28 matches
Mail list logo
