Mail fired a bit early there.
That said, I'm not against a {% doctype %} tag or anything. However, I
do think having an xhtml default is a Good Thing due to its backwards
compatibility. I'm also not entirely fond of the idea of having 100
different language outputs in Django. Why stop only after
This is a non-issue.
Correct me if I'm wrong, but is valid html syntax. It's parsed
as valid by every html parser, and I'm positive this is the entire
point of xhtml: staying backwards-compatible with html.
J. Leclanche / Adys
On Sat, Sep 26, 2009 at 7:48 AM, Rob Hudson wrote:
>
> Or: Why i
Or: Why is HTML4 such a PITA to get right?
Outline:
* What I know about HTML4 and Django
* Some info about past efforts and discussions
* Thoughts and curiosities about what we can do
What I know about HTML4 and Django
First, let's not let this turn into an argument
Ping. Anyone?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-
On Sep 25, 11:23 am, Ramiro Morales wrote:
>
> I suspect there is a clash between the names of your m2M and FK fields
> (category, category_id), try changing one of them so there isn't one
> relationship field with a name equal to the name of the other plus
> '_id'.
>
> Note that I'm not saying t
On Sep 25, 4:44 pm, Johannes Dollinger
wrote:
> Regarding parity, let me advertise a Signer object again:
>
> signer = signed.Signer(
> key=settings.SECRET_KEY,
> expire_after=3600
> )
>
> s = signer.sign(v)
> v = signer.unsign(s)
>
On Fri, Sep 25, 2009 at 3:10 PM, Daniel C. Silverstein (cubes)
wrote:
>
> The following model renders correctly when viewed in the admin
> interface:
> class Cms_Consumer_Reports(models.Model):
> [...]
> category = models.ManyToManyField('ontology.Category',
> db_table='map_cms_consu
Howdy,
I originally posted about this issue on django-users here:
http://groups.google.com/group/django-users/browse_thread/thread/ca79f4cb085566a5
After further discussion of the issue on #django, I believe I have hit
upon a genuine bug in the Django ORM layer so I am posting here.
The followin
On Thu, Sep 24, 2009 at 5:33 PM, Chris Beaven wrote:
>
> Personally, I don't see much point in specifically reporting on
> incorrectly signed cookies - imo they should just be treated as if
> they never existed. If someone really cared, they can look in
> request.COOKIES to see if the cookie was i
On Fri, Sep 25, 2009 at 10:42 AM, Simon Willison
wrote:
> On Sep 25, 3:39 pm, Simon Willison wrote:
>> While that makes sense for caching, I couldn't say if it makes sense
>> for signatures or not - when we sign something, will we always know
>> the point at which we want that signature to expir
> Would expire_after on the unsign just automatically imply
> timestamp=True? There's been a lot of concern raised about parity in
> the API, and it reads a little weird with the two different arguments.
> I'm not sure it's a problem, but it's just a little funny.
Regarding parity, let me advert
On Fri, Sep 25, 2009 at 11:22 AM, Lewis Taylor
wrote:
>
> I should have also noted all url resolves fail, not just with no
> arguments.
>
> On Sep 25, 4:11 pm, Lewis Taylor wrote:
> > Here it goes:
> >
> > I wanted a clean url structure so i tried to abstract as much as i
> > could in one url pat
I should have also noted all url resolves fail, not just with no
arguments.
On Sep 25, 4:11 pm, Lewis Taylor wrote:
> Here it goes:
>
> I wanted a clean url structure so i tried to abstract as much as i
> could in one url pattern. it looks something like this:
>
> url(r'^approved/((?P[a-zA-Z ,-]
Here it goes:
I wanted a clean url structure so i tried to abstract as much as i
could in one url pattern. it looks something like this:
url(r'^approved/((?P[a-zA-Z ,-]+)?)(/?)((?P[0-9]+)?)(/?)
$', get_approved_images, name='approved_images')
this in theory should allow the return of
1) all ima
On Sep 25, 3:39 pm, Simon Willison wrote:
> While that makes sense for caching, I couldn't say if it makes sense
> for signatures or not - when we sign something, will we always know
> the point at which we want that signature to expire? I don't know.
Here's a good argument for signing things wi
On Sep 25, 3:10 pm, Marty Alchin wrote:
> The timestamp would then be the actual expiration
> time, rather than the time it was signed, so the API can look like
> this instead (with a key added per prior discussion).
>
> >>> s = signed.sign('key', 'value')
> >>> v = signed.unsign('key', s)
> >>>
On Fri, Sep 25, 2009 at 9:26 AM, Simon Willison wrote:
> The API would look something like this:
>
s = signed.sign('value', timestamp=True)
v = signed.unsign(s, expire_after=24 * 60 * 60)
>
> A SignatureExpired exception would be raised if the signature was
> older than the expire_after
On Sep 25, 1:57 pm, Marty Alchin wrote:
> I think this is good for everywhere the raw signing API is accessed,
> perhaps to the point where that API can't even be used without a key
> (a namespace, really - honking great idea!). Helpers on top of that
> API could do without asking for that separa
On Sep 25, 1:57 pm, Marty Alchin wrote:
> I wish there was
> a way to sign the expiration as well, so people couldn't artificially
> extend the life of the cookie, but since that doesn't come back in the
> request, there'd be no way to validate it.
We can do that by baking the timestamp the cook
On Fri, Sep 25, 2009 at 7:02 AM, Luke Plant wrote:
> Suppose one part of an app signs an e-mail address for the purpose of
> an account confirmation link sent in an e-mail. The user won't be
> able to forge the link unless they know HMAC(SECRET_KEY, email).
>
> However, suppose another part of t
On Friday 25 September 2009 12:27:53 Simon Willison wrote:
> Do you have any further information on the WordPress problems?
No, I can't find it. It might not have been WordPress. All I remember
is that it was along the lines of what I outlined in my previous e-
mail -- one part of the applicat
On 9/24/09 9:56 PM, Ian Lewis wrote:
> On Fri, Sep 25, 2009 at 6:33 AM, Chris Beaven wrote:
>
>> +1 on the concept of a signing module.
>>
>> On Sep 25, 7:48 am, Marty Alchin wrote:
>>
>>
>>> The one downside to using get() directly, as opposed to an altogether
>>> new method, is that
On Sep 25, 12:02 pm, Luke Plant wrote:
> In other web apps (I think Wordpress?), there have been problems
> associated with use of secret keys when the same key is used for
> different purposes throughout the application.
> ...
> - we add unique prefixes to the SECRET_KEY for every different
>
On Sep 24, 3:46 pm, Simon Willison wrote:
> > 1) request.unsign_cookie('foo') -- This breaks the parallelism with
> > existing cookies. Sometimes we'll be doing request.COOKIES['foo'] and
> > sometimes we'll be doing request.unsign_cookie('foo').
>
> If we were going to do that, it would make s
On Thursday 24 September 2009 18:18:56 Simon Willison wrote:
> SECRET_KEY considerations
> =
Can I add some other things I've been worrying about while we're on
the topic?
In other web apps (I think Wordpress?), there have been problems
associated with use of secret ke
On Sep 25, 4:48 am, Russell Keith-Magee
wrote:
> By way of greasing the wheels towards trunk: if the outcome of this
> mailing list thread was a wiki page that digested all the ideas,
> concerns and issues into a single page, it will make the final
> approval process much easier.
Great idea: htt
26 matches
Mail list logo
