On 6/14/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> On 6/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> > It's up here:
> > http://www.b-list.org/weblog/2006/06/13/how-django-processes-request
>
*sigh*. And now that I go to actually review yours, I see you linked
Simon's already. Ignore
On 6/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
> It's up here:
> http://www.b-list.org/weblog/2006/06/13/how-django-processes-request
You're doing a more thorough thing, but this is a nice backgrounder to
compare/contrast:
http://simon.incutio.com/archive/2005/08/15/request
--~--~---
In response to a comment I got the other day on my blog, I've written
a first draft of a document detailing, from start to finish, how
Django processes a request. I'd love to get feedback, suggestions and
corrections on this so I can refine it into a really useful write-up,
so if you have a few mi
On 14-Jun-06, at 10:54 AM, Deryck Hodge wrote:
> Maybe not entirely appropriate on the developers list, so please
> forgive
>
> Just wanted to say from one project to another, thanks for the
> great tool.
> We've just moved our Samba news site into Django.
>
> http://news.samba.org/announc
Maybe not entirely appropriate on the developers list, so please
forgive
Just wanted to say from one project to another, thanks for the great tool.
We've just moved our Samba news site into Django.
http://news.samba.org/announcements/we_go_django/
Cheers,
deryck
--
Deryck Hodge
http://www
Jay Parlar wrote:
> So what I'm thinking, is to allow something like the following:
>
> class User(models.Model):
> username = models.CharField(...)
> avatar = models.ImageField(upload_to="users/" + self.username,
> erase_old=True)
>
For "upload_to" case I think this will work:
upl
So I've been thinking a lot recently about FileField/UploadField, and
how restricting they are for any app that might want users to upload
files.
Namely, the fact that the upload_to can only use strftime() to vary
the directories.
I did submit a patch (http://code.djangoproject.com/ticket/1994)
Hi,
Pro:
- secure by default: you do not miss one variable because you have to
explicitly disable it for a variable, I would prefer a little more
verbose syntax like: {{ variable|noescape }}.
Con:
- explicit escaping is better then implicit escaping (no magic behind
the scenes)
I like your idea
Here's how I see it:
- 99% of the time, templates are HTML
- most template variables should be escaped
- developers are human and will miss variables that need escaping
My proposal is that all templates variables are escaped by default.
Think about it for a bit before you throw the idea away. T
(seems that when you say edit-as-new in thunderbird, it keeps the
in-reply-to header. how usefulsorry again)
hi,
i tried to implement the validation-logic for some of the fields, but
while looking at the source code, i found this inconsistency...
question:
class S
(sorry for the double-post. i only later realized that replying to a
previous thread is not a good idea)
hi,
i tried to implement the validation-logic for some of the fields, but
while looking at the source code, i found this inconsistency...
question:
class SlugField
Adrian Holovaty wrote:
> On 6/7/06, gabor <[EMAIL PROTECTED]> wrote:
>> so now the decisions are already done, and when all the fields will have
>> the necessare to_python (+validate) methods, then save will be changed
>> to call validate, and the task is done?
>>
>> or still some decisions have t
Custom manipulators are a pain. Could we think about integrating this
cookbook recipie into Django? Or at least start a dialogue about
improving this process.
http://code.djangoproject.com/wiki/CookBookManipulatorCustomManipulator
--~--~-~--~~~---~--~~
You recei
Op di, 06-06-2006 te 08:05 -0700, schreef hugo:
> (it's rather silly to not allow root servers to use port 6667 ...
> especially the client-side of it ...)
I guess they fear IRC wars (including DDoS attacks) and malicious bots
used by scriptkiddies. And Hetzner did already have a note on their
14 matches
Mail list logo
