On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> - If there's some other way to spell form.protect(response).
Here's a crazy idea that might just work:
class AddArticleForm(forms.SafeForm):
headline = forms.CharField()
# ...
def add_article(request):
form = AddArticleForm
On Sep 22, 11:09 pm, Jan Oberst <[EMAIL PROTECTED]> wrote:
> I'd protect all my forms if there's a neat way to do it. Why would it
> only apply to logged-in users? I'm not using contrib.auth.
It doesn't need to only apply to contrib.auth logged in users, but it
should only be used for forms which
On Sep 22, 10:21 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> This makes me think -- is it possible that CSRF protection at the form
> level is too low? Perhaps it's something that needs to be happening
> at, say, the view level? Some sort of decorator, and/or a tag to spit
> out the CSRF
On Sep 22, 10:01 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> > > -- What about third-party app forms that aren't SafeForms, but need to
> > > be? The situation dictates this, not the form author.
> > I think we keep CSRF middleware around to deal with that. We also very
> > actively encourage thi
On Sep 22, 9:41 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> -- What about third-party app forms that aren't SafeForms, but need to
> be? The situation dictates this, not the form author.
I think we keep CSRF middleware around to deal with that. We also very
actively encourage third party apps to
On Sep 22, 9:03 pm, Andrew Godwin <[EMAIL PROTECTED]> wrote:
> 2) I'm not sure how common a use case this is; it sounds like it might
> be verging into the long tail a bit.
I think denormalisation is much more common than many people think. I
can think of a couple of reasons you might want to den
CSRF[1] is one of the most common web application vulnerabilities, but
continues to have very poor awareness in the developer community.
Django ships with CSRF protection in the form of middleware, but it's
off by default. I'm willing to bet most people don't turn it on.
I don't believe middlewar
On Sep 18, 11:58 pm, SmileyChris <[EMAIL PROTECTED]> wrote:
> I think you missed the point, Simon.
>
> Michael isn't talking about self-referencing extending, he's talking
> about blocks in statically included templates ({% include "bit.htm"
> %}).
Ah yes, sorry - misunderstood the original e-mai
On Sep 18, 6:39 pm, Michael Elsdörfer <[EMAIL PROTECTED]> wrote:
> I remember this coming up on django-users and IRC once or twice, and
> never thought too much about it, but currently, template inheritance
> and includes don't work together at all:
>
> * Blocks included in a parent template cann
On Sep 16, 7:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> @register.tag
> @uses_token_stream
> def mytag(parser, bits):
> expr = bits.parse_expression(required=True)
> return MyNode(expr)
>
> `uses_token_stream` replaces the Token argument to the parser
> function with a Toke
On Sep 16, 1:03 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> This is a call to review ticket #1105. The proposed patch is fully
> functional, backwards-compatible and contains tests and
> documentation.http://code.djangoproject.com/ticket/1105
>
> Currently it is not possible to access the cont
On Sep 12, 7:45 pm, Brent Hagany <[EMAIL PROTECTED]> wrote:
> As far as I can tell, the argument about being portable is a good one,
> and if that ends up being the reason this doesn't get in right away,
> then I can't complain. However, the part about the single server
> making this more special
On Sep 12, 10:46 pm, TP <[EMAIL PROTECTED]> wrote:
> > This means an ORM object should have a
> > special property on it recording which database connection it was
> > loaded from. It also presumes we won't ever want to support the case
>
> I apologize for my ignorance as to how django DB connecti
On Sep 12, 5:11 pm, mengel <[EMAIL PROTECTED]> wrote:
> > obj = Article.objects.using('master').get(pk = 4)
> > obj.name = 'Hello'
> > obj.save(using = 'master')
>
> Shouldn't the object remember the database used to fetch it, and
> save() should save it back there? Then you would only have to
On Sep 10, 10:55 pm, ab <[EMAIL PROTECTED]> wrote:
> For the api to accept a DSN, alias, or connection anywhere would add
> similar code in multiple places. I propose that the aliases are mapped
> into django.db.connections. For your example, you could use
> django.db.connections.archive.
I'm kee
On Sep 10, 10:44 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Well... To be sure save() should always go to master because on slaves
> you just don't have permissions to save anything. So a parameter to
> save() is redundant.
It's redundant in the case of a single master, but there are other
si
On Sep 10, 10:24 pm, "Mike Malone" <[EMAIL PROTECTED]> wrote:
> At Pownce, for example, we stick users to the master database for some
> period of time (a couple of seconds, usually) after they post a new note.
> The problem here (as Malcolm pointed out) is that related managers use the
> default
On Sep 10, 10:15 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > * Simple master-slave replication: SELECT queries are distributed
> > between slaves, while UPDATE and DELETE statements are sent to
> > the master.
>
> It won't wo
On Sep 10, 9:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Oh, please, no! Registration is a very fragile process. It simply
> doesn't work very well. It's a bit disappointing that it's the way we
> have to do things that way in places in Django and if we can avoid it
> elsewhere that'd b
On Sep 10, 5:29 pm, "Rob Hudson" <[EMAIL PROTECTED]> wrote:
> To avoid adding yet another setting (unless it's warranted here) can
> the setting of a doctype in a template tag set a value in
> django.conf.settings that django.forms can then check (with a
> reasonable default)?
>
> I recall seeing
On Sep 10, 7:13 pm, "Justin Fagnani" <[EMAIL PROTECTED]> wrote:
> For application-wide db connections, I think it'd be much easier and
> more portable to choose the connection in settings.py rather than in a
> Model.
That's a very interesting point, and one I hadn't considered. It makes
sense to
On Sep 10, 7:17 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Also, as a general thing here, did you go back and read the various
> discussions we had about API when the multi-db Summer of Code project
> was running? If not, that would be worth doing and incorporating, since
> we debated a f
For those who weren't at DjangoCon, here's the state of play with
regards to multi-db support: Django actually supports multiple
database connections right now: the Query class (in django/db/models/
sql/query.py) accepts a connection argument to its constructor, and
the QuerySet class (django/db/m
On Sep 10, 3:32 am, Ville Säävuori <[EMAIL PROTECTED]> wrote:
> About the {% doctype %} tag, should we then maintain a (potentially
> long?) list of different doctypes and/or should there be a way to
> define your own?
I think we should maintain a list of doctypes - there really aren't
that many:
On Sep 8, 6:03 am, akaihola <[EMAIL PROTECTED]> wrote:
> I couldn't find a ticket for this issue yet. Simon, mind if I create a
> ticket and dump your description of the issue there?
I've filed it here:
http://code.djangoproject.com/ticket/9002
--~--~-~--~~~---~--~--
On Sep 10, 12:24 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> OK, enough noise on the naming.
(I really like metronome)
> Let's talk about what it should be and what should be measured. :)
> (I suspect some devs already have a sketch regarding this stuff.
> Please share.)
>
> Do we want it t
Back in March there was a discussion about providing a way to output
django.forms widgets as HTML (at the moment they always use XHTML,
which leads to nastyness on sites using an HTML doctype):
http://groups.google.com/group/django-developers/browse_thread/thread/5f3694b8a19fb9a1/
On the plane b
On Sep 8, 5:36 am, Erik Allik <[EMAIL PROTECTED]> wrote:
> I'm glad this came up, because I would also like to recommend
> considering an admin interface for models that use django-mptt. I know
> django-mptt is an external project but I think many people are using
> django-mptt as it's curre
On Sep 8, 2:46 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I don't think this would be too hard to implement either. The URL
> routing would have to be redesigned though, as it is currently not
> very flexible. Maybe something like the following to edit multiple
> objects on the same page:http:
On Sep 7, 10:03 pm, akaihola <[EMAIL PROTECTED]> wrote:
> I couldn't find a ticket for this issue yet. Simon, mind if I create a
> ticket and dump your description of the issue there?
Go for it!
--~--~-~--~~~---~--~~
You received this message because you are sub
I wrote up a work-around for this issue a while ago. If you need to be
able to over-ride your "base.html" template with a new template also
called "base.html" you can do it by adding an overall parent directory
to your TEMPLATE_DIRS setting which allows you to provide a fully
qualified path to the
On Aug 19, 1:39 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> (And you know, I still think we'd be better off with
> "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad
> more seriously, something like "django-community" and "django-core" —
> otherwise we'll be fighting this batt
On Jul 7, 3:00 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> I've just uploaded a patch to #6017 that will hopefully address this
> issue. The patch 'django-admin-tests.diff' contains a prototype test
> framework for django-admin and manage.py scripts. It works by spawning
> a child proce
On Jun 28, 11:21 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> MD5 is 8 chars shorter. Do we really need SHA-1? If I understand
> correctly, the only known vulnerability with MD5 is the ability to
> force collisions, but that will not help an attacker in this case.
> The only thing that an attacker
On Jun 28, 10:01 pm, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> If you add the timestamp into both the hash and the token then you can
> achieve a more granular expiration policy.
That's the approach I use for djangopeople.net - the problem is that
including the timestamp lengthens the URL yet f
On Jun 28, 12:29 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> https://example.com/reset/34-7127f83ebf8ce7ed22bdc50a50572a30
>
> i.e.
>
> https://example.com/reset/{uid}-{hash}
I've been playing with this a bit and the one thing that was
concerning me is that the UID on large sites can end up being
On Jun 28, 7:58 pm, "Adi J. Sieker" <[EMAIL PROTECTED]> wrote:
> <[EMAIL PROTECTED]> wrote:
> > That's absolutely ingenious - that approach gets my vote. I think I'll
> > switch DjangoPeople over to that.
>
> and to have the token expire you could add the date of the following day
> into the has
On Jun 28, 1:39 am, "Scott Moonen" <[EMAIL PROTECTED]> wrote:
> I don't think it's necessary to implement this in such a way that additional
> server state is stored. Instead, you could let the confirmation token be a
> hash of the internal user state -- including, most importantly, the user
> pa
On Jun 28, 1:12 am, Luke Plant <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] said the following:
> > I'd suggest making the code to change the password a one-use-only
> > item though, so that even if someone did sniff the code, it'd be
> > useless after that.
>
> The problem with this is it req
On Jun 27, 12:44 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Does a FileUploadHandler object have access to the
> content length sent by the browser?
D'oh, it's right there in the docs - FileUploadHandler.new_file(self,
field_name, file_name, content_type, content_l
On Jun 26, 8:14 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Documentation of the new features is can be found in
> ``docs/upload_handling.txt``
> orhttp://code.djangoproject.com/git/?p=django;a=blob_plain;f=docs/uploa
Just a small thing:
"""
Like any data supplied by the user, you
On Jun 18, 7:08 am, jurian <[EMAIL PROTECTED]> wrote:
> I recently ran in to the a problem/snag when overriding the admin
> index page. The thing is that I would like to change the index
> displayed for a specific application, and not the entire admin index.
>
> So I though that it might be a good
On Jun 16, 10:00 am, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I have just added a patch that allows a simple_tag to receive the
> context as first argument, like inclusion_tag already does. It is
> backward compatible.
>
> I'd like to get some feedback on the code, so feel free to check it
> out
On Jun 14, 12:26 am, Devin <[EMAIL PROTECTED]> wrote:
> So to integrate Selenium tests with the test framework already in
> place, I've added live server support for TestCase for ticket
> 2879.http://code.djangoproject.com/ticket/2879#comment:27
That's pretty cool. Any chance you could provide a
On Jun 1, 8:20 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> So, how about an idea of adding request, object, and action to
> ModelAdmin instances in newforms-admin code rather than in user code
> and refactoring newforms-admin code based on this decision?
We've used that exact trick recently a
On May 29, 12:21 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> We had some discussions during PyCon in Chicago, the biggest issue we
> have with the hooks is the amount of code needed to change the widgets
>
> we talked with Joseph about something like widget-sets, a mapping prom
> either field, o
We (GCap, large commercial radio company in the UK) have been
developing against the newforms-admin branch for a few months now, and
based on that experience I have a number of suggestions for simple
hooks that could be added to make it easier to customise.
1. Provide a custom template for a chan
On May 22, 6:53 pm, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> Simon Willison wrote:
> > Thankfully Ivan Sagalaev's confusingly named mysql_cluster
>
> BTW does anyone have a suggestion how to rename it? I've picked
> mysql_cluster simply because I didn't k
I have to admit I'm slightly worried about the multi-database
proposal, because at the moment it doesn't seem to solve either of the
multi-db problems I'm concerned about.
The proposal at the moment deals with having different models live in
different databases - for example, the Forum applicatio
On May 15, 11:36 pm, Luke Plant <[EMAIL PROTECTED]> wrote:
> I've been using twill integrated into Django unit tests (as described
> here:http://www.djangosnippets.org/snippets/665/), but came across
> the problem that exceptions are hidden by Django's exception
> handling, so it's very difficult
On May 14, 3:51 pm, Ken Arnold <[EMAIL PROTECTED]> wrote:
> 4. Other tags and filters, like include, ssi, and truncatewords (from
> a quick scan) that perform some function that could fail, should mark
> that failure very clearly in the output. (Those two currently do, but
> the error string is ea
On May 14, 3:02 pm, George Vilches <[EMAIL PROTECTED]> wrote:
> On May 14, 2008, at 9:58 AM, Simon Willison wrote:
> > Silent errors are bad. If we were to remove them, how much of a
> > negative impact would it have on the existing user base?
>
> I suspect that a lot
Hi all,
Some time in late 2003, Adrian and I decided that errors in templates
were best handled silently - the idea was that it would prevent
untrained template editors from being able to 500-error a site with a
typo.
Is it too late to reconsider this decision, four and a half years
later? I can
there if you have any more
questions.
http://groups.google.com/group/django-users/browse_thread/thread/1d3cd3bcd0bb3e6b
Best regards,
Simon Willison
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developer
On Apr 27, 6:37 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> - The slow operation is resetting the database. As far as I know,
> there isn't much that can be done about this. No matter which way you
> do it, deleting a whole lot of data then re-establishing database
> structure is an exp
On Apr 27, 1:59 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Its mostly there as a convenience for the really simple cases. There
> some duplication in typing annotate(avg_height=Avg('height'), so the
> shortcut is a convenience. IMHO, this is the sort of thing could be
> easily explaine
On Apr 27, 4:04 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> I merged queryset-refactor into trunk just now. This was changeset
> r7477.
Fantastic! Congratulations, and thank you.
One of my favourite new features is the ability to more easily see the
SQL that is going to be run against th
On Apr 26, 12:33 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> So - here's a slightly modified proposal. Last time this topic came up
> on django-dev, Justin Fagnani made an interesting suggestion which I
> think will answer your objections, and leaves open some interesting
> possibiliti
On Apr 26, 7:34 am, "Ian Kelly" <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 25, 2008 at 11:40 PM, Russell Keith-Magee
>
> <[EMAIL PROTECTED]> wrote:
> > > Have you considered syntax that looks like this instead? :
> > > >>> Students.objects.all().aggregate({'average_height': 'height__avg})
> > >
like this instead? :
>>> Students.objects.all().aggregate({'average_height': 'height__avg})
> {'average_height' : 1.43}
That way the API feels like you are passing in an example of the data
structure you want, and Django is using your example and filling in
the gaps fo
On Apr 20, 11:23 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> -1 for the reasons that James Bennett stated above. That it crashes
> and burns in production is actually a feature in this case.
If we want to crash and burn if you use DEBUG=True in production we
should do that explicitly, n
On Apr 17, 5:04 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> Middleware is easy to set and forget. Is there a reason not to make
> SecureForm the default, and InsecureForm for people using Ajax? ;-)
I'm pretty sure we can handle the Ajax case by not doing CSRF token
checks if request.is_ajax
I've noticed that a LOT of people get bitten by the problem where
every SQL statement is logged if DEBUG=True, resulting in huge memory
consumption after a while. This problem seems particularly common for
import scripts, which are often run in development (hence with DEBUG
on) and can involve tho
On Apr 11, 4:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> On Fri, Apr 11, 2008 at 8:56 PM, Simon Willison <[EMAIL PROTECTED]> wrote:
>
> > def render(self, context):
> > "Display stage -- can be called many times"
> >
Here's something that has been quietly bugging me about Django for /
years/:
Context() is an implementation detail of the template engine. Having
to instantiate a Context just to pass it to render() is unnecessary
boilerplate (and means you have to import another symbol as well).
Template.render
http://code.djangoproject.com/ticket/6776
newforms-admin raises an AlreadyRegistered exception if you attempt to
register a model with admin.site twice. Unfortunately, due to the
different places and ways in which a models.py file can be imported
it's extremely easy to trigger this accidentally,
On Apr 7, 8:19 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 7, 2008 at 9:09 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'm also mostly in agreement here.
>
> As am I. Syntax is tough, of course; here's my two cents::
>
> form = ModelForm(model=Person, exclude=["p
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining t
On Apr 7, 2:15 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> > I'd still like to see form_for_model stay (or be replaced by the above
> > or similar) rather than being deprecated.
>
> Personally I don't see much call for it; dynamically building a
> ModelForm is easy enough, and maintaining t
On Apr 7, 1:05 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> I suppose I could dynamically
> construct a ModelForm subclass at runtime (any pointers on how to do
> that, including dynamically creating the inner class called "Meta",
> would be welcome) bu
form_for_model is marked as deprecated but ModelForm does not appear
to be a full replacement for it. Given an arbitrary model class (i.e.
one that is defined at runtime, not at "compile" time) there is no
clear way of creating a form from it using the ModelForm mechanism.
Here's what I am doing
't seem to have made any
changes that would result in a substantial speed increase.
Cheers,
Simon Willison
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
On 17 Dec 2007, at 08:08, James Bennett wrote:
> This means the default implementation can happily use
> django.contrib.auth and the existing is_staff flag and permission
> system, but that using something else is as easy as subclassing and
> overriding the right methods. And with a little refac
On 8 Dec 2007, at 20:14, Kevin Menard wrote:
> Shifting to a more personal stance, I never cared much for the term
> "Web 2.0". It seems too gimmicky. That's largely the impression I
> get with a Django 2.0 without a prior Django 1.0.
The other problem with Django 2.0 is that Rails just relea
On 4 Dec 2007, at 13:26, bobj wrote:
> Simon - These are GREAT!!! Ideas. The regular expression based URL
> dispatching replacement has been something I personally have been
> thinking about for some time. I would be interested in helping with
> this If you put together a proposal. One URL imp
On 3 Dec 2007, at 08:15, James Bennett wrote:
> At that point I'd wonder why Django had any machinery for
> request/response processing, middleware, etc., given that what you're
> describing is more neatly handled by just writing a WSGI application
> and taking advantage of the existing tools.
On 3 Dec 2007, at 15:45, Malcolm Tredinnick wrote:
> -1 from me.
>
> I've already responded at least three times on the users list why this
> wouldn't be a good idea. We should indeed do a release after that
> stuff
> is merged. It will be called 1.0 (or 2.0 or whatever).
Ta, should have looked
It's fantastic that 1.0 (or whatever it ends up being called) is now
under serious discussion, but are there any plans for a numbered
release before then? I've been asked by a few people if they should
be running svn or a numbered release - with auto-escaping now in
trunk it seems a new nu
On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> What am I forgetting?
It's probably too big a feature to start talking about now, but I'd be
really interested in seeing Django applications (in particular the
URLconf part) unified with the concept of a Django view, so a Django
a
On Dec 1, 2:02 am, Simon Willison <[EMAIL PROTECTED]> wrote:
> Here's an idea that's been kicking around in the back of my head for
> far too long: Django Enhancement Proposals, or DEPs.
For further context it's worth reading PEP 1, which describes PEPs and
how they w
Here's an idea that's been kicking around in the back of my head for
far too long: Django Enhancement Proposals, or DEPs. At the moment,
large changes to Django (auto escaping, queryset refactor etc) are
discussed in quite an ad-hoc way - if you want to stay completely up
to date on them you need
On Nov 30, 6:33 am, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> I think we ought to call the release 2.0.
I'm -0.5 on this (if that's possible). I understand the thinking
behind it, but "1.0" isn't an arbitrary version number - it has a very
specific meaning: "the APIs are frozen, it's safe to
On Aug 2, 9:39 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> Yuck, clients that don't speak HTTP correctly make me angry.
>
> Reading the RFC, though, I see that since HTTP 1.0 made "charset"
> optional, it remains so in HTTP 1.1, and we're supposed to "guess" and
> use ISO-8859-1 like you'
On Aug 1, 7:56 pm, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> Set autoescaping on by default for anything ending in ``.html`` (and,
> perhaps, ``.htm``), and off otherwise.
I've been thinking about this a bit, and it seems like it could work
well if it was done the other way round - basically, auto
On May 25, 1:25 pm, "Clint Ecker" <[EMAIL PROTECTED]> wrote:
> Should they be every week regardless of whether there were 1 or 10
> worthy developments, or should the author wait until X number of good
> links have been culled until a post is made, no matter the time in
> between posts. I might be
On May 11, 4:23 pm, Niels <[EMAIL PROTECTED]> wrote:
> > Or you could use the traditional
> > Unix password invalidator -- "!" -- which might be more mnemonic for
> > some people and is easier to pick out of a data dump than a space (and
> > will also never be a valid string, since we use '$' as a
On May 11, 3:40 pm, Martin Winkler <[EMAIL PROTECTED]> wrote:
> > Certainly Oracle treats them empty string as equal to NULL. But does
> > that mean you can't put an empty string in a "not NULL" column in
> > Oracle?
>
> Exactly. If you want to insert something meaningless into a column that
> has
On May 11, 7:50 am, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > At the moment, django.contrib.auth does not support creating a user
> > account without setting a password.
>
> Why not generate a random one? It won't break an ability to authenticate
> using OpenID or any other backend for that mat
I'm working on a new component for my Django OpenID package which will
provide support for associating one or more OpenIDs with a
django.contrib.auth User. As part of this, I want to include the
ability to register for a new user account using an OpenID instead of
a password.
At the moment, djang
James Bennett wrote:
> On 8/9/06, Jason Huggins <[EMAIL PROTECTED]> wrote:
> > I can see how a policy like that is "tricky"... What's to keep an evil
> > blackhat from subscribing to the very same list so he he knows when to
> > get busy cracking sites using the same information?
>
> I've been wat
On 28 Jul 2006, at 13:06, Todd O'Bryan wrote:
> What if we deprecated {{ }} and replaced it with an escape tag and a
> raw tag? It would keep backward compatibility, but would encourage
> people to use escaped strings unless they have a reason to use raw
> ones. I suppose we don't really have to
On 28 Jul 2006, at 01:50, Ahmad Alhashemi wrote:
> Default escaping couples the Django templates with HTML. I don't think
> that this is a good idea, even if HTML is, incidentally, the most
> commonly used language in templates, for the time being.
Here's an idea I don't think anyone has brough
On 27 Jul 2006, at 21:01, Tom Tobin wrote:
> From what I recall of conversations on the subject, default behavior
> will not be changed to auto-escape. Auto-escaping, under whatever
> proposal is accepted, will require some form of action to enable.
I like to think that's not set in stone yet. T
On 27 Jul 2006, at 07:07, [EMAIL PROTECTED] wrote:
> So the db/models/query.py parse_lookup() expansion loop would include:
>
> if type(value) == types.FunctionType:
> value = value()
>
> I've tested such a change on Django 0.95 - it seems to work OK.
A neater way of
On 19 Jul 2006, at 15:43, David Larlet wrote:
> I'd like to know if it's possible to have access to django slides of
> Simon's conf at Europython 2006.
I've uploaded my slides to the conference site:
http://indico.cern.ch/contributionDisplay.py?
contribId=26&sessionId=9&confId=44
They're a 2
On 19 Jul 2006, at 15:30, Ivan Sagalaev wrote:
> I just thought that may be they shouldn't. If META is a reflection of
> CGI's environment that is derived from HTTP environment that is
> essentially in byte strings then I think META being unicode is may be
> useless and misleading.
>
> Instead t
On 19 Jul 2006, at 14:37, Gábor Farkas wrote:
> 1. request.META should contain raw bytestrings (like it's currently)
> 2. request.META should contain unicode strings. for QUERY_STRING, we
> should convert it to unicode using the 'ascii' charset. and we should
> not url-decode it.
request.META s
On 19 Jul 2006, at 13:19, Ivan Sagalaev wrote:
> Talking about QUERY_STRING... While the string itself is in ASCII
> it has
> urlencoded data and there the encoding matters. As fas as I can see in
> practice browsers tend to encode those data in the same encoding as
> the
> page from where t
On 18 Jul 2006, at 23:30, gabor wrote:
> 1. django publishes the whole environ dictionary as request.META. the
> environ dictionary is a normal byte-string dictionary. so, should we
> convert it to unicode so that the request.META dictionary only
> contains
> unicode strings?
>
> 1.a: if yes,
On 18 Jul 2006, at 16:19, Tyson Tate wrote:
> Is there any way I can get a response on this? I really hate to be
> annoying and pedantic, but the following problems are literally show-
> stopper problems for my Django projects and they're holding up what
> is otherwise a working project. I would
101 - 200 of 297 matches
Mail list logo
