Re: Session/cookie based messages (#4604)
On Sun, Sep 20, 2009 at 6:13 PM, Chris Beaven wrote: > Having some kind of defacto cross-request notification system makes > sense; it's a very common usage pattern. > Attaching these kind of messages to a User instance is wrong: there is > not an enforced one to one correlation between a user and a session > [1], and you can't notify anonymous sessions. > Exactly. What makes this such a pressing issue for me is that the current user.message_set implementation directly *encourages* the (bad) habit of attaching messages to a user, without offering a more extensible alternative. There are many situations in which the message_set implementation breaks down and reasons why a more robust standard is needed, and needs to be blessed by the core developers. To mention a few: 1) it's not possible to create messages for anonymous users 2) if the same Django user is logged in twice on different computers simultaneously, they see each others' messages 3) as Chris mentioned, messages may get wiped even if they're not actually displayed to the user 4) high-load sites want to avoid the unneeded database or cache usage 5) since the built-in implementation is broken and no standard exists, reusable apps don't know what system to use and hence cannot rely on providing session feedback 6) it's debatably a more common problem than anything else in contrib: A site that doesn't allow users to login (hence no contrib.auth) may still need session-specific feedback. Implementation-wise, it's also a very simple problem. Sessions and cookies will cover 95% of the use cases at hand. Both are necessary for a couple reasons: cookies may not be large enough to store all messages, and the session may be more expensive to use (and hence should be avoided if possible). For the remaining 5%, it's incredibly easy to write a custom backend in at least one of the messaging/notification options out there. In my mind what we need now is more eyes on the code and more feedback about the pros and cons of each option out there. Perhaps something as simple as a wiki-based table would do. I've previously summed up the criteria for what I think would make a solid notification engine and only found one app that did it, but that may have changed and there are probably options out there that I don't know about. My post and the feedback I received can be found here: http://www.caktusgroup.com/blog/2009/06/19/towards-a-standard-for-django-session-messages/ On a side note, I talked with Simon about this at the sprints and he made the point that we also need a genuine, cryptography expert-approved cookie-signing utility in the core, which this messaging/notification app would ideally use. The issue, as I understand it, is that we want to be certain pickling misc. objects and sticking them in a cookie is actually secure, and not rely on (with all due respect) [some random cookie signing implementation]. Tobias --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee < freakboy3...@gmail.com> wrote: > > You also mention that there are a number of other implementations, but > you haven't really given a compelling survey or analysis of the > alternatives - you've just blessed one in particular. Why? > I started a wiki page comparing some of the different options out there: http://code.djangoproject.com/wiki/SessionMessages Feel free to update with (your messaging backend here). Tobias --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
Vaclav, I think this is less of an issue, because you'd have to switch to another tab and perform a second operation that generated feedback in the ~200 millisecond window of time between clicking a link and the new page loading. If you need to support this functionality, you could write a storage to put the message directly in the URL query string, either by adding it to the request Location header for HttpResponseRedirect objects or by parsing the response output and sticking in the extra parameter for all URLs on the page, but this is obviously pretty ugly and in my mind not worth the effort. Tobias On Tue, Sep 22, 2009 at 11:17 AM, veena wrote: > > Hi Tobias, > good idea with start a wiki page. > > I'm not sure if we don't forget one issue. > > How about same session (or same cookie sent by browser) with > simultaneously opened windows of one browser? Then message could > appear in different window not the right one where we invoke the > event. Is it a problem? Is only possibility to get of this issue that > flash app should add a query parameter into redirected url which would > identify the right window? > > Vaclav > > > > > On Sep 22, 3:08 am, Tobias McNulty wrote: > > On Sun, Sep 20, 2009 at 10:24 AM, Russell Keith-Magee < > > > > freakboy3...@gmail.com> wrote: > > > > > You also mention that there are a number of other implementations, but > > > you haven't really given a compelling survey or analysis of the > > > alternatives - you've just blessed one in particular. Why? > > > > I started a wiki page comparing some of the different options out there: > http://code.djangoproject.com/wiki/SessionMessages > > > > Feel free to update with (your messaging backend here). > > > > Tobias > > > --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Sep 22, 2009 at 9:51 PM, Russell Keith-Magee wrote: > In reality, I get a ping time closer to 300 ms. And that's to a > high-end data center under ideal conditions - it can be much larger if > I'm dealing with low end providers. > What?? 200 ms is the average quoted by Mr. Sproutcore himself! No, in all seriousness, my apologies for making such a broad generalization about packet latency. I could/should have said 500 ms or even a second; the argument and corresponding solution, if needed, remain the same. Anyways..we digress. I am marking this a non-issue in my own head - please pipe up if there's a case to be made. Tobias --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Adding signing (and signed cookies) to Django core
+1 for signed cookies. Your API looks reasonable and I'd agree that
set_cookie(..., signed=True) fits better with the rest of the API as well.
What about some sanity checking to make sure that, if SECRET_KEY is used, it
is, at the very least, a non-empty string?
On Thu, Sep 24, 2009 at 1:18 PM, Simon Willison wrote:
>
> As mentioned in the thread about cookie-based notifications, at the
> DjangoCon Sprints I raised the subject of adding signing (and signed
> cookies) to Django core.
>
> I've found myself using signing more and more over time, and I think
> it's a concept which is common enough to deserve inclusion in Django -
> if anything, its use should be actively encouraged by the framework.
>
> It's also something that's hard to do correctly. At the sprints Armin
> pointed out that I should be using hmac, not straight sha1, for
> generating signatures (something Django itself gets wrong in the few
> places that implement signing already). Having a cryptographer-
> approved implementation will save a lot of people from making the same
> mistakes.
>
> Signed cookies
> ==
>
> On top of signing (which I imagine would live in django.utils) I'd
> like to add a signed cookie implementation. Signed cookies are useful
> for all sorts of things - most importantly, they can be used in place
> of sessions in many places, which improves performance (and overall
> scalability) by removing the need to access a persistent session
> backend on every hit. Set the user's username in a signed cookie and
> you can display "Logged in as X" messages on every page without any
> persistence layer calls at all.
>
> I think signed cookies should either be a separate API from
> response.set_cookie or should be provided as an additional argument to
> that method. I'm not a fan of signing using middleware (as seen in
> http://code.google.com/p/django-signedcookies/ ) since that approach
> signs everything - some cookies, such as those used by Google
> Analytics, need to remain unsigned.
>
> So the API could either be:
>
>response.set_signed_cookie(key, value)
>
> Or...
>
>response.set_cookie(key, value, signed=True)
>
> (I prefer the latter option)
>
> Proposed signing implementation
> ===
>
> I'd be happy to donate my signing code from django-openid to the
> cause, which was written to be usable entirely separately from the
> rest of the django-openid codebase:
>
> http://github.com/simonw/django-openid/blob/master/django_openid/signed.py
>
> http://github.com/simonw/django-openid/blob/master/django_openid/tests/signing_tests.py
>
> This offers two APIs: sign/unsign and dumps/loads. sign and unsign
> generate and append signatures to bytestrings and confirm that they
> have not been tampered with. dumps and loads can be used to create
> signed pickles of arbitrary Python objects.
>
> Here's what the API would look like with this library:
>
> >>> from django.utils import signed
> >>> signed.sign('hello')
> 'hello.9asVJn9dfv6qLJ_BYObzF7mmH8c'
>
> The signature is a URL-safe base64 encoded digest of the hmac/sha1. I
> used base64 rather than .hexdigest() for space reasons - base64
> digests are 27 characters, hexadecimal digests are 40. When you're
> including signatures in cookies and URLs (especially account recovery
> URLs sent out in plain text, 80 character wide e-mails) every byte
> counts.
>
> >>> signed.unsign('hello.9asVJn9dfv6qLJ_BYObzF7mmH8c')
> 'hello'
> >>> signed.unsign('hello.badsignature')
> Traceback (most recent call last):
> ...
> BadSignature: Signature failed: badsignature
>
> BadSignature is a subclass of ValueError, meaning lazy developers
> (like myself) can do the following rather than importing the exception
> itself:
>
> try:
>value = signed.unsign(signed_value)
> except ValueError:
>return tamper_error_view(request)
>
> >>> signed.dumps({"a": "foo"})
> 'KGRwMApTJ2EnCnAxClMnZm9vJwpwMgpzLg.mYepoYkzWwXRmsCTVJm3Mb0HHz4'
> >>> signed.loads(_)
> {'a': 'foo'}
>
> Again, the pickle is URL-safe base64 encoded to take up less valuable
> cookie space and generally make it easier to pass around on the Web. A
> nice thing about URL-safe base64 is that it uses 64 out of the 65 URL-
> safe characters (by URL-safe I mean characters that are left unchanged
> by Python's urllib.urlencode function) - the remaining character is
> the period, which I use to separate the pickle from the signature.
>
> signed.dumps takes a couple of extra optional arguments. The first is
> compress=True (default is False) which zlib compresses the pickle if
> doing so will save any space:
>
> >>> import this # to get an object worth compressing
> ...
> >>> len(signed.dumps(this.s))
> 1207
> >>> len(signed.dumps(this.s, compress=True))
> 637
>
> By default, all signatures use Django's SECRET_KEY. If you want to
> sign with a different key, you can pass it as an argument to the
> various functions:
>
> >>> signed.sign('hello', key='sekrit')
> 'hello.o6MKehoOfZ2b2FU84wzibW6IWxI'
> >>> sign
Re: Adding signing (and signed cookies) to Django core
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 in there but not in > SIGNED_COOKIES. I suppose. IMHO silent failures are usually a bad thing. I generally like to know if (a) there's an error on my site, or (b) someone is trying to do something nasty, even if all that means is: try: ... except BadSignature: pass # or a log.debug(...) Tobias --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch: adding a msg parameter to assertContains and similar methods in the test client
On Thu, Oct 8, 2009 at 11:58 AM, Wes Winham wrote: > This gives me a nice little summary. I know that there were more foo's > displayed on the page than there should have been. I second that. The option to specify a quick message explaining what the failure means, for anyone who didn't write the test, can be the difference between a 2 minute fix and a half hour+ debugging session. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
In hopes of jump starting this conversation once again, I made some significant changes to the wiki page that try to sum up the state of the conversation so far in a better way: http://code.djangoproject.com/wiki/SessionMessages Things that still need to be discussed/done: * Coming to consensus on what 3rd party app we actually choose to extend/modify to fit into Django * What to do with the existing user message API (see http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI) * Review/add to the TODO list on the wiki (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen) Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sat, Oct 10, 2009 at 1:19 PM, Tobias McNulty wrote:
> Things that still need to be discussed/done:
>
> * Coming to consensus on what 3rd party app we actually choose to
> extend/modify to fit into Django
>
> * What to do with the existing user message API (see
> http://code.djangoproject.com/wiki/SessionMessages#IntegratingwiththeExistingAPI)
>
> * Review/add to the TODO list on the wiki
> (http://code.djangoproject.com/wiki/SessionMessages#TODOOnceaSolutionisChosen)
I should have also added:
* Coming to consensus on a de facto standard API suitable for
inclusion in Django
I originally put it on the TODO list, but in retrospect the discussion
needn't wait till we pick a solution.
As a practical starting point, I copied the API for django-notify to
the wiki page. I like the general form of that API, but I'd be
slightly more happy with something like:
from django.contrib import messages
request.messages.add('message', messages.INFO)
# or
request.messages.add('message', classes=(messages.WARNING,))
# or
request.messages.error('message')
A la python logging, I think endorsing a specific set of message
classes or tags (but still allowing them to be extended) is A Good
Thing because it helps reusable apps provide more customized feedback
in a standard way.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sat, Oct 10, 2009 at 2:05 PM, David Cramer wrote: > The proposal per your email is more or less how django-notices works. For comparison I added django-notices to the Available Options: http://code.djangoproject.com/wiki/SessionMessages#AvailableOptions -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sat, Oct 10, 2009 at 6:44 PM, Hanne Moa wrote: > The suggested API: how hard will it be to use different message-types > in addition to the syslog-like ones? I think it should definitely be easy, if not actively encouraged. IMO those constants should just be strings, or integers which can easily be mapped to strings (like in Python logging). This would give you the flexibility of passing in anything you want. django-notices does it the latter way: http://github.com/dcramer/django-notices/blob/master/django_notices/constants.py I clarified that criterion in the wiki: http://code.djangoproject.com/wiki/SessionMessages#Criteria -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Sat, Oct 10, 2009 at 7:03 PM, veena wrote: > Today I was on very bad wifi connection. Constantly dropped. 20 > seconds to load a page. > I save in admin in two tabs and got a notice in one tab from the other > tab. > > But I agree, I defer this "bug" for the first release od django > messaging. I think django isn't now in right mood to add there some > functionality like adding of query parameters to response object by > some application. Maybe in future. AFAIK this will become a non-issue with the advent of HTML5, as each window/tab will have its own session. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
404 debug pages should show the name of the tried urlpattern - #9310
In case it's not already on someone's radar, the patch on this ticket could use a review at some point: http://code.djangoproject.com/ticket/9310 Thanks - Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
can't pass instance=None to inline formset - #11872
Another quick bug fix that should be ready for review/check-in: http://code.djangoproject.com/ticket/11872 -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 10:21 AM, David Cramer wrote: > I also don't think this problem is being addressed here. Yes you could > pass messages to the context, but you would lose the ability to > retrieve those variably. I believe storing it in the existing session > is the best appoach for django's builtin support. I'm not exactly sure what problem you see as not being addressed, and I don't think you were arguing against this, but it has been noted elsewhere that it's more desirable to store the messages directly in a cookie, if possible, to avoid the extra database or cache hit. It seems well worth it to me and there are solutions out there that try to store the messages in a cookie and then fall back to the session for longer (>4kb) messages. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 11:42 AM, Paul McLanahan wrote: > For me, the best solution would be a combination of django-notify and > django-notices. django-notify for their fallback backend and the > interchangeable backend support in general, and django-notices for the > logger-like API. I especially like the NOTICE_LEVEL setting which > could easily be controlled via your DEBUG setting. I agree that custom > levels should be easy and encouraged, and the strings used even for > the built-in levels should be configurable. I'm with you 100%. The criteria on the wiki page say as much, but I should probably clarify that django-notify does not actually provide any default levels/classes/tags yet. Thanks for the feedback. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 11:52 AM, David Cramer wrote: > I would definitely say it needs to be configurable then at the least. > As using cookies to send messges is fine if you guarantee the entity > is removed onthe next hit. Otherwise it becomes a performance issue > storing them for longer periods of time. > > While I don't think that is common it should definitely be a factor in > the decision. django-notify lets you plug in a pure session storage if that's what you want. And if you do use cookies, they'll get removed 90% of the time on the next request, and in most other cases removed on the subsequent request (e.g., in the case of 2+ chained redirects). The point is just to keep them around until they're actually displayed, not indefinitely. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 11:53 AM, Paul McLanahan wrote:
> For the potential API...
>
> http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI
>
> It would be really nice if one could optionally iterate over the
> message lists separately. For example:
I have no particular issue with allowing messages to be iterated in
full and/or by type. We could also just sort the messages and let you
use {% regroup messages by tag %}, but I suppose you want the ability
to pull out a particular type of error and that could get tedious with
{% regroup %}.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 2:02 PM, David Cramer wrote:
> I'm -1 on adding .errors or whatever. The main reasoning being that "levels"
> are simply numeric values (even though django-notices does provide default
> labels for its built-ins). Regroup is very easy and I don't think this is
> something that needs built-in, as there's no better way to optimize it than
> regroup. However, with doing this it'd be very important that it doesn't
> clear the messages unless you're pulling it out. django-notices handles this
> by popping out elements in the iter (I believe), so that if you don't pop
> the message out, it's still present.
In Python logging the levels are integers, but you still get
convenience methods like logger.error('msg'), etc.
I don't see why a similar method to filter the messages by type would
be a bad thing.
For the record I have no personal need for this feature (and hence
strong feelings about it), but nor do I see why adding it would be a
bad thing IF the need is actually there. Right now it sounds like
regroup will work fine for its original proponent, so, in the interest
of keeping things simple, let's assume it will not be included unless
someone brings up a compelling case.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Mon, Oct 12, 2009 at 3:06 PM, Paul McLanahan wrote: > Tobias: Are you planning on coding up a proposal app? It doesn't sound > like there's far to go from a branch or fork of django-notify. I > should have some time to contribute to the code or testing if you need > it. Thanks for offering up your time. Once there seems to be a general consensus about where we're going I plan to do that, yes. We're getting closer but I'm not convinced we're there, yet. Before we get too far, I'd appreciate hearing feedback from one or more of the core devs (and from some of the folks who were involved in this discussion back when it was happening on the ticket) on the wiki page[1] and the general direction this project is going. Tobias [1] http://code.djangoproject.com/wiki/SessionMessages -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 12:13 AM, Chris Beaven wrote:
> One thought: It would be backwards incompatible to change
> {{ messages }}, it's already being used for User messages. To avoid
> confusion, I have consistently steered away from using the term
> "messages" by itself in documentation and code. I see that the wiki
> page doesn't make the same distinction.
Yes, that's a choice we'll have to make. Most folks seem to default to
calling them messages (or maybe that's just me).
That said, I see your point. What about {{ request.messages }}? Is
that still going to be confusing? Whatever the name becomes, I don't
really see the need for the extra context processor. You'll likely be
writing the name far more often in your views than in your templates.
This also raises the issue of how this app will live side by side with
User messages. I threw out a few ideas on the wiki (give User
messages a much narrower purpose than they have now and/or phase them
out altogether), but I'm sure there are other (probably better) ones.
My only real issue with "notifications" is that it's more letters to
type and fewer letters in the actual message (before the line hits 80
chars).
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 3:53 AM, Hanne Moa wrote: > In fact, it would be very useful to both log and add a message at the > same time, iff there is an error. So that shouldn't deliberately be > made hard to do but maybe suitable for a lazy man's shortcut: one call > that does both. That is binding together two technologies that are still fairly conceptual in terms of their integration with Django at this point. I'm a little worried that we wouldn't get it right the first time around. The extreme case would involve implementing messaging as a python logging handler. Frankly I'm not sure it's worth it. Furthermore, "error" message to the user may not always be, in fact often probably isn't, an error for the web app, so it'd be important to differentiate between the two. E.g., you might want to log an ERROR message under the INFO python logging level. Short of providing this do-all call in the implementation itself, I see a few options: 1) write your own wrapper if you do a lot of that 2) add some logging calls to the messaging code so that you can see messages that were shown to the user if you want to, under a static logging level (e.g., INFO) I like #2, provided that the default logging handler in Django is a NullHandler (I think it is/will be). Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 3:27 AM, Russell Keith-Magee wrote: > as an alias. Note that this is a reversal of argument order from the > proposed API. I'm not absolutely tied to this suggestion - I'm just > noting that adding Django support for Python logging is also on the > cards for v1.2, and it seems weird that we would introduce two APIs > with similar external APIs, but not try to maintain parity. I updated the API on the wiki. The levels/classes will likely be different, because logging and messaging are two very different things, but keeping the argument order the same is probably a good thing. > Secondly, I share Chris' concern about overloading 'messages'. This > overlaps with the bikeshed issue of what to call the new contrib > package - whatever name is picked for the contrib package should > probably be reflected in the context variable, etc. Okay, let's pick something other than 'messages' and stick to it. I'm fine with "notifications", "notices", and maybe even "notes", but the last one is a little ambiguous. Other ideas? > Lastly, one issue that seems unaddressed is the transition plan for > replacing user.message_set. The preamble to the wiki page makes a > compelling argument for ditching message_set, but remains silent on a > proposal for how Django (as a project) should be treating this new > alternative. > > The solution might well be "use it if you want, ignore it if you > don't", but given the problems with user.message_set, it might be > worth giving some thought to a deprecation/transition plan. I think the deprecation plan would look something like this: 1.2: user.message_set is officially deprecated but continues to work unaffected 1.3: user.message_set is still usable, but raises a deprecation warning when it is used 1.4: user.message_set is removed Are we comfortable ditching the auth Message model altogether (several releases from now), or is someone actually using it for a legitimate purpose that won't be supplanted by the proposed app? Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 9:48 AM, Jacob Kaplan-Moss wrote: > This is my main concern, and the thing keeping me from being > enthusiastic about the current state of the proposal. Many apps -- > including, notably, django.contrib.admin -- rely on user.message_set. > We can't simply remove it; we need to follow a deprecation schedule. > But we also shouldn't just keep two parallel "messaging" > implementations; that's silly. > > The best solution, I think, would be to implement user messages > (user.message_set, get_and_delete_messages, etc) in terms of the new > framework, and then gradually deprecate and remove the old APIs. I think this is a large reason why the original attempt to get this ticket fixed fell apart: User messages and session messages are two completely different beasts and trying to fit them into the same API is somewhat of a dead end. The proposed app would function better for contrib.admin than what exists now, so I'm confident that if we introduce/deprecate in a gradual way the necessary changes can be made easily and on a reasonable schedule. I don't envision updating the admin in this release but someone correct me if there's an issue with not doing it right away. I'm not sure exactly what you mean by implement user messages in terms of the new framework. It is completely possible to implement a storage engine in several of the proposed solutions that would use user.message_set to store data, though I'm not sure what the advantage would be over any of the other options. Furthermore, the fact that user.message_set is just a related manager on a model and not an independent API per se makes it a difficult one to remove while simultaneously keeping user message functionality. Unless there is a compelling use case for user-based messages that really sets it apart from the proposed app (and there may very well be, I just haven't heard it yet), my vote is to deprecate the Message model in contrib.auth in a gradual way and remove it altogether several releases down the road. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 9:54 AM, Paul McLanahan wrote: > This may be adding undue complexity, but I wanted to throw it out and > see what you thought anyway. I think a possible solution to Russ' last > two points may indeed be overloading the "messages" template variable. > What I'm thinking is that we keep the message_set (of course) and add > the new "request.messages.*" API, but completely remove the messages > part of the auth context_processor and have the default backend for > the new system pull both for the first release (purely for backward > comparability). Messages from the old message_set system could get a > default level in the new system. This shouldn't be an issue since the > people using it will likely be existing projects where they won't be > using any level information in their templates. We couple this > combined backend with settings that will allow you to easily disable > the DB part of the backend (or make it clear how to and strongly > suggest switching backends), and provide a setting for the default > message level that defaults to INFO. As a developer I'd rather make the conscious switch from one technology to the other. IMHO I don't think the effort and potential confusion of making everyone's templates "just work" is worth it. Chris, I know you have some personal experience trying to get session- and user-based messages to work together, so I think we'd benefit from any wisdom you might be able to offer. :) Toby -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
Just a couple random thoughts/clarifications after reading the Django 1.2 feature votes: * The proposed messaging app will definitely leverage the cookie signing utilities also in store for 1.2. * This is a compelling core feature for me, at least, because a standard needs to be set that reusable apps can take advantage of. Currently everyone rolls his or her own solution or depends on (with all due respect) some random 3rd party app (or at least that's how it feels when one is trying to integrate two apps that use different messaging backends). * Developing a plan to integrate with user.message_set (and potentially deprecate the old API) is a key priority and something we DO need to hammer out more. That said I think we can get it done. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Oct 13, 2009 at 8:13 PM, Russell Keith-Magee wrote: > I was hoping for a little more detail than this - this is just > Django's general deprecation plan, and I wouldn't expect that to > change. What exactly do these steps mean in practice? What changes are > going to be made to (for example) admin? Are there any other apps that > will be affected? What will happen when I update from 1.2-1.3? > 1.3-1.4? Is there a need for a transition API (e.g., a 'message_set' > descriptor that actually sends messages to the new message backend)? I put up a skeleton of a plan (not much more than what I sent before) on the wiki: http://code.djangoproject.com/wiki/SessionMessages#DeprecationPlan There are still a few things missing (like what apps actually need to be updated) but hopefully that'll provide us a place to keep track of the details. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Thu, Oct 15, 2009 at 5:45 AM, Tai Lee wrote: > My personal bike shed is named "alerts", but other than that I have > nothing to add that hasn't already been mentioned. I've been using > django-notify for a while now, and think it's great. Can't wait to see > something like it make it's way into core. That's an option. It's short and doesn't conflict with anything that I know of. I added a section to the wiki with potential app names: http://code.djangoproject.com/wiki/SessionMessages#PotentialAppNames -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Wed, Oct 14, 2009 at 10:27 AM, Jacob Kaplan-Moss wrote: > I'm trying to avoid having two incompatible messaging systems in > Django. I agree that linking messages to sessions makes more sense > than linking them to users [1], but we can't just remove the user > messages API outright. I'd like a good transition strategy, so it > seems the best way would be to keep the user messages API, but switch > it to use session messages under the hood. I know a solution like this was attempted and then abandoned earlier in the ticket history. Chris, do you have any wisdom to share about this? I expect it may be complicated because I can't think of a clean way to get the current request (and hence the session messages variable) inside the User model. Maybe I'm missing something. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Thu, Oct 15, 2009 at 7:03 PM, SmileyChris wrote:
> If we are to slowly deprecate this functionality, I think that we
> should do effectively the same thing.
> Leave user messages as-is and use something like this as the default
> message storage:
Just to make sure I understand this correctly, let me try to summarize
what this would mean:
* the proposed app controls {{ messages }} and is responsible for
retrieving anything set in the Message model
* old apps that call user.message_set.create will still get their
messages to the screen, assuming the project uses {{ messages }} in
the template
* old apps that call get_and_delete_messages or iterate through the
Message.objects.all() manually will NOT see any messages that were
stored in the session or a cookie, but they will continue to see
messages created the old way
* judging from your code, the new app will NOT store any messages in
the old Message model, it will only read them
* the standard template code:
{% if messages %}
{% for message in messages %}
{{ message }}
{% endfor %}
{% endif %}
will continue to work untouched after the update. For those that
choose to leverage it, a {{message.level}} (or otherwise named
attribute) will also be available.
* since we are tying ourselves to the {{ messages }} variable, this
probably means that the app should be called 'messages'. There has
been some hesitation about this. Are we in the clear now that we have
a potential upgrade path from the old API? Or is there still concern
about naming?
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant wrote: > I think this means that either the deprecation cycle would have to > pushed back one (i.e. pending deprecation warning in 1.3, deprecation > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2. I > would strongly prefer the latter, and this would affect my vote: I > don't want two messaging systems in Django, and if user messages are > not deprecated, then we do have two systems. I agree that using deprecated code in the core is setting a bad example. A quick review of the code shows 8 calls to message_set.create: 3 in auth, 2 in admin, and 3 in the create/update/delete family of generic views. This definitely sounds to me like a manageable update for 1.2. Per feedback from Jacob, Chris, and Luke, I updated the notes on the existing API, the transition plan, and the potential API on the wiki: http://code.djangoproject.com/wiki/SessionMessages Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Can you add a build-in template tags?
On Sun, Oct 18, 2009 at 12:18 PM, butterhuang wrote:
> There is a templatetags {% include 'x.html' %}, it's very nice. may a
> templatetags like {% include no-parse "x.html"} is needed. It's so
> powerful to improve the speed of include some static files which has
> no variable,and it's so easy for you guys, isn't it?
This would be a lot easier to discuss if you (or someone else) can
show us (a) an implementation of such a tag, and (b) some profiling
numbers that demonstrate significant savings with your method.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
For reference purposes, I started a branch of django on bitbucket with a contrib.messages app heavily based on django_notify (only renamed/updated to reflect the API on the wiki): http://bitbucket.org/tobias.mcnulty/django-contrib-messages/ It's a work in progress and I'll be updating it in the coming days/weeks but feel free to try it out/push back any changes you see fit. Tobias On Fri, Oct 16, 2009 at 2:10 PM, David Cramer wrote: > I agree, this is 30 minutes of work to change the usage in Django, and it > should be done with the inclusion of the messages patch. > > > David Cramer > > > > On Fri, Oct 16, 2009 at 1:08 PM, Tobias McNulty > wrote: >> >> On Fri, Oct 16, 2009 at 5:10 AM, Luke Plant wrote: >> > I think this means that either the deprecation cycle would have to >> > pushed back one (i.e. pending deprecation warning in 1.3, deprecation >> > in 1.4, removed in 1.5), or core/contrib should be fixed by 1.2. I >> > would strongly prefer the latter, and this would affect my vote: I >> > don't want two messaging systems in Django, and if user messages are >> > not deprecated, then we do have two systems. >> >> I agree that using deprecated code in the core is setting a bad >> example. A quick review of the code shows 8 calls to >> message_set.create: 3 in auth, 2 in admin, and 3 in the >> create/update/delete family of generic views. This definitely sounds >> to me like a manageable update for 1.2. >> >> Per feedback from Jacob, Chris, and Luke, I updated the notes on the >> existing API, the transition plan, and the potential API on the wiki: >> >> http://code.djangoproject.com/wiki/SessionMessages >> >> Cheers, >> Tobias >> >> >> -- >> Tobias McNulty >> Caktus Consulting Group, LLC >> P.O. Box 1454 >> Carrboro, NC 27510 >> (919) 951-0052 >> http://www.caktusgroup.com >> >> > > > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Fri, Oct 16, 2009 at 2:10 PM, David Cramer wrote: > I agree, this is 30 minutes of work to change the usage in Django, and it > should be done with the inclusion of the messages patch. I'm working on migrating auth, admin, and the create_update generic views to use messages in my bitbucket branch. I updated them all to use request.messages.add() and things work great as long as one has the middleware and context processor enabled for django.contrib.messages. This obviously won't be the case, however, when everyone initially updates to Django 1.2. There are a couple ways around this that I see: 1) raise an error stating that the MessageMiddleware and 'messages' context processor need to be installed, like the admin does for the SessionMiddleware, e.g.: assert hasattr(request, 'messages'), "The Django admin requires message middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to insert 'django.contrib.messages.middleware.MessageMiddleware'." 2) add a compatibility method to the messages app that looks for messages and falls back to user.message_set if the middleware hasn't been enabled, e.g.: def compat_add_message(request, level, message): """ Attempt to add a message to the request using the 'messages' app, falling back to the user's message_set if MessageMiddleware hasn't been enabled. """ if hasattr(request, 'messages'): request.messages.add(level, message) elif hasattr(request, 'user') and request.user.is_authenticated(): request.user.message_set.create(message=message) In sticking with the staged deprecation policy, my vote would be: * use compat_add_message() internally in 1.2. There is no need to document this function as request.message_set.create will continue to work. * in 1.3, remove compat_add_message and raise an error if 'messages' isn't enabled when you try to use the admin or create_update generic views, etc. I could be convinced to skip the compatibility function and go straight to raising an error, but that seems like a big jump. I updated the branch to do basically this, but nothing is set in stone. Thoughts? Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Thu, Oct 22, 2009 at 6:56 AM, Luke Plant wrote:
> I've started to look at the code, and have some other minor
> suggestions, but not significant things to do with approach, so I'll
> e-mail you personally with them at some point. On the basis of what
> I've seen so far, I'm willing to change my vote on this to +1, which
> at the moment would make me the 'champion' for this feature, as no-one
> has voted -1. At the moment, the big areas that are lacking are:
>
> - user docs
> - code docs (I'm curious about things like EOFMessage, there
> is nothing to explain why it exists).
> - changes and complete tests for the auth context processor,
> including the different configurations that are allowed
> (with and without the messages app, for instance). I think
> the auth context processor should call the messages one,
> so that you get the same result whether you use one or
> the other or both.
Thanks for your support and feedback. I'll get started on the docs
and other changes you mention. There's a small issue with the auth
context processor returning what the messages one does: it's currently
the responsibility of the middleware to create the Storage object that
is request.messages, so this won't exist if the middleware isn't
installed.
We could: (a) instantiate a new Storage instance for the {{ messages
}} variable if request.messages doesn't exist (in the context
processor), or (b) introduce another compat_* method that tries to
retrieve messages from request.messages, and falls back to
user.message_set if the middleware hasn't been enabled. I'd be more
comfortable with (b) since I'm not certain what all the ramifications
of (a) would be (and there wouldn't be much point anyway, since
there'd be no way to get a message into the cookie or session storages
without the middleware).
Now that I think about it, this is probably what you meant and just
wanted to make sure the messages context_processor will do the same
thing. I'll update the code.
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--~--~-~--~~~---~--~~
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-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Thu, Oct 22, 2009 at 2:30 PM, James Bennett wrote: > > On Thu, Oct 22, 2009 at 10:27 AM, Phillip Temple > wrote: >> django-registration - rewritten to have pluggable work flow, this is a >> fundamental feature of so many web sites > > I'm -1 on adding django-registration to contrib. Agreed. The "pluggable work flow" that is Django itself works quite well for me. -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Django 1.2 feature voting
On Sat, Oct 24, 2009 at 9:32 AM, rjc wrote: > BTW, we use django evolution since south doesn't support python 2.3 > (again a lot of > enterprise code is stuck at RHEL4 which is py2.3) It sounds to me like you already have a solution and some special needs that make the current choice you have in schema evolution tools a Good Thing. Integrating something into the core may tie to you to a specific implementation that doesn't really suite your needs. So what's the big rush? Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 1.2 Feature Suggestion
On Sun, Oct 25, 2009 at 7:39 PM, Dan wrote: > > I didn't know about rosetta. What would you guys think of having a doc > section about popular third party apps? I think this is best done through a third party site. Look at the success of DjangoGigs. I don't know that there's a de facto place to look for apps yet, but I bet a winner will emerge in time. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: project folder with dots
On Mon, Oct 26, 2009 at 8:23 PM, Kevin Teague wrote: > > It's Python which doesn't allow dots in the name of a package, > although it's Django which is putting the name of your project name on > sys.path. This was intentional, see the django.core.management > package: > ># Import the project module. We add the parent directory to > PYTHONPATH to ># avoid some of the path errors new users can have. > > To fix the code is easy enough. But to update all of the relevant > documentation and to require all existing Django deployments to have > to migrate their project structures (or change all of their imports) > to upgrade is a much bigger issue to tackle. In the long run, this > would be a good change, since the current situation is confusing and > can cause a lot of problems - but I think it will take a fair bit of > effort and championing to fix it. IMHO the project namespace is a useful one to keep around. If you lose the project name space, then you risk polluting your python path with a lot of generic 'urls' modules, among other things. If your directory structure on your server includes the domain name, then include the project folder under that. There's nothing stopping you from housing more generic apps outside the project namespace. On a related note, an on-going pet peeve of mine is that manage.py leaves '.' on the python path. This can be confusing for new users who are trying to figure out how to structure their imports. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: project folder with dots
On Tue, Oct 27, 2009 at 4:06 PM, Kevin Teague wrote: > Structure a Django project so it has the same layout as a normal > Python project. Which might look something like: > >myinstance/ >setup.py >settings.py >bin/ >manage.py >mysite/ >__init__.py >urls.py > I can't think of any serious objections to your proposal, other than that it's a big change from the way things are done now and I'm not sure what the transition plan would involve. I'd say, if you are serious about it, create a proposal on the wiki that outlines why this has to happen, when it should happen, if this has been tried before, what the benefits would be, what problems would have to be solved, and how to solve them. My unqualified opinion is of course subject to veto by any of the powers at be (though I should think anyone is free to make serious, well thought out proposals in the wiki, whatever they might be). :) Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Inline Formsets Again
major roadblocks here. Django should easily handle the common cases, > not try to enforce good web design. > > I've written a creaky hack to work around the issue in my own projects > but after seeing this thread I'm going to take a shot at implementing > FormSetField (or something like it) myself. If anyone has any code - > or more arguments for or against that haven't been covered - I'd love > to hear them before diving in. > > John Debs > > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Enhanced debug output colors: django code is green, user code is red.
I'm not a big fan of the red/green either. They imply that Django code is "bad" and user code is "good". What about something more subtle, like different shades of gray for the background and/or text, to draw your attention to the user code while making it easier to gloss over the Django code (but still readable if necessary)? Tobias On Mon, Nov 2, 2009 at 6:57 PM, Gabriel Hurley wrote: > > I'm not sure about the exact colors, but the visual distinction is a > big plus in my book. > > One possible place to document it would be in the information > regarding the TEMPLATE_DEBUG setting here: > http://docs.djangoproject.com/en/dev/ref/settings/#template-debug > > - Gabriel > > On Nov 2, 2:03 pm, Dougal Matthews wrote: > > 2009/11/2 Yuri Baburov > > > > > > > > > > > > > > > > > Hi All, > > > > > Since you are discussing and applying different features, > > > > > I think it's time to ask what do you think of the subj. > > > > > It's athttp://code.djangoproject.com/ticket/11834 > > > > > It adds some helpful color beauty to django 500 output. > > > > > Sample pictures are here: > > >http://code.djangoproject.com/attachment/ticket/11834/11834.pngand > > >http://code.djangoproject.com/attachment/ticket/11834/11834_2.png > > > > > I'm not a designer, so feedback is highly appreciated > > > > I really like this, I always scan the traceback looking for items with > with > > .virtualenv in the path so I can ignore them - its bugged me for a while. > > This is clearly a better solution. > > > > I'm no designer either but I perhapsit could do with a bit of attention > from > > one, I'm not that keen on the red (pink?) and green mix. > > > > Also, documentation will be needed so users know what the colours mean > but > > I'm not sure where in the docs. I can't see anything on the current error > > page. > > > > Dougal > > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
I've added some user docs to my bitbucket branch and would much appreciate any feedback from the group, as I'm much too steeped in it at this point to tell what's clear and what isn't: http://bitbucket.org/tobias.mcnulty/django-contrib-messages/src/tip/docs/ref/contrib/messages.txt If your comments wouldn't benefit from discussion, feel free to email them to my privately to avoid swamping the list. Thanks, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Enhanced debug output colors: django code is green, user code is red.
On Tue, Nov 3, 2009 at 8:31 AM, Yuri Baburov wrote: > > On Tue, Nov 3, 2009 at 9:27 AM, Tobias McNulty > wrote: > > I'm not a big fan of the red/green either. They imply that Django code > is > > "bad" and user code is "good". > The opposite, in fact. > Django code is green, "good", user code is red, "untrusted". Whoops, my bad. I still think there are concerns about the colors, however. They imply that something is wrong with the red code, which might not be the case. There is also the concern of whether or not these colors are distinguishable to colorblind folks. I think what you need to try to do is make the user code draw your attention first, and the Django code draw your attention second. I don't think the current color scheme does that in an effective way. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Tue, Nov 3, 2009 at 12:57 PM, Jacob Kaplan-Moss wrote: > Yes, please. > > Special-casing built-in backends requires more code and leads to the > impression that external backends are somehow second-class citizens > This isn't -- or shouldn't be -- true. Sounds better to me as well; I'll make the change. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com --~--~-~--~~~---~--~~ 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-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Session/cookie based messages (#4604)
On Thu, Nov 5, 2009 at 9:15 AM, Russell Keith-Magee wrote: > * In the discussion about message levels mentions tags before tags > have been introduced. The section on levels should introduce the > messaging levels without reference to the tagging process. > Fixed. > * The explanation of tags says they are a 'string representation', > but doesn't clarify what that string is useful for. Is it a verbose, > human readable name? An identifier? A name suitable for a CSS class? > Added. > * There also seems to be a lot of attention paid to the numerical > values for constants. Ordinarily, you don't really care about the > numerical values of system constants - you just use them. To my mind, > the numerical values of the constants are irrelevant until you get to > the 'custom level' section - where they are only relevant because you > need to know the numbers you can't use. > Moved listing of values to the custom level section and added descriptions of levels in the original spot. > * The example custom level CRITICAL doesn't have a consistent value - > it's 50 in places, 60 in others. > Whoops, thanks for catching. > * The explanation around minimum recorded message levels could do > with some elaboration. It isn't entirely clear to me what the > message.level setting does - is it a minimum level? maximum level? > inclusive or exclusive? The example here needs to be richer - showing > an example of a message that _won't_ be stored, for example. > Good call. Added. > * Similarly for extra tags - are the extra tags concatenated onto > message.tags? Are spaces added? will message.tags become a list? > I think it basically said that already but I tried to clarify what was there, and added some explanation about how tags are stored, in general, in the first section on tags. I'd be open to the argument that tags should be stored in a list instead of a string, in case you want to do other things with them and/or space delineation doesn't work for you. * The description of LegacyFallbackStorage storage could do with some > elaboration. I'd almost go so far as to say that there should be a > whole section in the docs about this storage backend, and exactly how > it operates - the original list where the storage engines are > introduced should provide a link to a more detailed section. Questions > that need to be addressed: > >* In what order are messages retrieved from cookie,session and database? >* Do I need to do anything to my existing user.message_set code? >* What level do old-style messages get? > Added. * Following the lead of contrib.comments, you may want to consider > splitting the settings documentation into a separate documentation > module. > Seems silly for just 3 settings, especially since the settings are already documented on a separate page (the full list of settings), but it looks like that's all comments has too. So, if it's the new convention and other apps are doing the same, I'll split it up. > On a code level - I noticed that the messages middleware is in the > list of defaults in the settings.py template, but not in > global_settings.py. A minor inconsistency, but one I noticed while > trying to work out exactly what the transition requirements would be > for existing projects. > Whoops, thanks for catching that. Added. > I had a quick poke around the rest of the code base, especially about > transition issues. However, I didn't want to start in on a big > teardown unless you thought the code was ready for it. When you're > ready for a the full latex-glove treatment, let me know. :-) > Will do. I have a little cleanup to do regarding EOFMessage per some feedback from Luke Plant but I think it should be ready soon. Thanks for all your feedback thus far! Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Session/cookie based messages (#4604)
On Thu, Nov 5, 2009 at 9:15 AM, Russell Keith-Magee wrote: > > I had a quick poke around the rest of the code base, especially about > transition issues. However, I didn't want to start in on a big > teardown unless you thought the code was ready for it. When you're > ready for a the full latex-glove treatment, let me know. :-) > Tear it apart :-) Diff showing latest changes in branch uploaded to ticket: http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-9f54c0f8719c.diff Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Session/cookie based messages (#4604)
Hi Russell, thanks for all your feedback. I'll review the small issues in a separate email (or just fix them), but here are my responses to the two bigger problems. On Fri, Nov 20, 2009 at 3:29 AM, Russell Keith-Magee wrote: > * I think there's a circular reference problem in the middleware with > the setup for request.messages. The messages middleware actually > creates request.messages, but the auth middleware creates a lazy > evaluator that can return request.messages. This means that as a > request comes in, the request is always given a lazy evaluator for > user.messages_set, which is then overwritten by the messages > middleware. The consequence of this is that any middleware that is > executed between the auth and messages processors will get > user.message_set if they try to set a message. > The auth middleware now returns the same thing the messages middleware does, so that may change the problem a little. Still, I'm not sure what the consequence would be of using messages between the two middlewares. I'll give it some thought and propose/implement a fix if it looks problematic. > * I have some concerns about the thread-safety (or, rather, > request-safety) of the various backends. If I'm reading the code > right, if you have two parallel requests, a message written in one > response will overwrite a message written in the second, which will > result in the first message never being displayed to the user. This > wasn't a problem with the old API because messages were written to the > database on response, and read on request; the first request would get > all the messages. If we're using cookies and sessions, there's all > sorts of clobbering problems. > True. One simple solution would be to offer another "thread safe" backend that used the database as a storage (independent of the User model of course). As long as we note the lack of thread safety in the cookie and session backends I think they'll still be alright for most cases; hopefully this is something that folks using sessions and cookies are prepared to deal with. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
Re: Session/cookie based messages (#4604)
er is given - a list of messages. I added the dictionary traversal to make the implementation more complete, though it's not really needed for the way messages are currently stored. * The _store() method on the session backend appears to rely on > implicit return values. > Fixed. > * Shouldn't the LegacyFallbackStorage class be using > user._message_set, rather than the message_set wrapper? If the user is > using a known legacy wrapper, we don't need to raise > PendingDeprecation warnings every time they use the backend. > Fixed. > * The 1.2 release docs will need an entry describing this changeset, > both for the feature and the upgrade steps required. > Added. > * The deprecation notes should explicitly mention all the APIs that > will be deprecated - the current text of "and associated APIs" isn't > particularly specific about what will be deprecated. > Fixed. > * The updated documentation about the auth context processor > shouldn't mention the old-style user.message_set API. If it's > deprecated, it's deprecated. However, it's ok to mention the old API > in the versionchanged note. (i.e., Prior to v1.2, request.messages was > a lazy accessor for user.message_set) > Fixed. > * In the auth docs, you can use the ..deprecated sphinx tag as the > analog for ..versionadded and ..versionchanged. > Added. > * In the docs about LegacyFallbackStorage, you don't need to repeat > or explain Django's deprecation policy - just say that the policy will > be followed and provide a link to the original source. > Removed. Additionally, per your other email, I added some notes to the docs about behavior of parallel requests from the same client. Again, the only thing I can think of that still needs to be worked out is the details of the API and whether or not it should be decoupled from request. I'm in favor of the idea, I'm just not sure what solution makes the best sense yet (see above). Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
On Mon, Nov 30, 2009 at 7:28 AM, Russell Keith-Magee wrote: > I'll take another look at this patch next week to make sure I haven't > missed anything. Assuming I don't find anything new and interesting > (and assuming you're happy with my response on the API issues), this > should be able to land in trunk in the very near future. > Your API suggestions sound fine; at least, as long as what messages is doing import-wise isn't any worse than the rest of Django, it's fine with me. :) Since this is a fairly significant change I would like to hear feedback from others before moving forward, in case there's something we missed. I updated the wiki to reflect the new proposed API: http://code.djangoproject.com/wiki/SessionMessages#PotentialAPI Once the final API changes have been made, I'll put up another patch, hopefully before next week. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Django development sprint in the Triangle, Dec 12-13
Hi All, Just wanted to let you know that we'll be hosting a local Django Development sprint in the Triangle area of North Carolina next weekend (Dec 12 and 13). A development sprint is an excuse to get together, write some code, and have a good time doing it. The purpose of this sprint will be to help finish features and push out bug fixes in preparation for the Django 1.2 release. If you're interested in coming to work on other open source Django-based projects, that's welcome too. We'll be meeting in Carrboro Creative Coworking (205 Lloyd St, Carrboro, NC 27510) and we'll be there to open the doors at 9am both days. For more information, please check out the corresponding wiki page and RSVP via Eventbrite if you're interested: http://code.djangoproject.com/wiki/Sprint200912TriangleNC http://django-triangle-dec-09.eventbrite.com/ We have a couple sponsors so far, but there's still room for more, so check out the sponsors section of the wiki and add yourself (or your company) if you'd like to bring something. Hope to see you there! Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
Sorry for the wait. You should have access now. :) On Tue, Dec 1, 2009 at 8:26 PM, SmileyChris wrote: > I applied and pushed all but your final whitespace revision. > > When Tobias reads this thread again, I'm sure he'll give you commit. > The fail_silently sounds good, and yes these failures were a rather > big oversight. > > On Dec 2, 10:35 am, Luke Plant wrote: > > I've been going through the code carefully now, and I've got a bunch > > of patches, mainly very minor (attached as a mercurial bundle, use "hg > > in fixes.bundle" to view, or if you give me commit rights to your > > repository I'll commit directly), and one significant issue: > > > > If I read the patch correctly, when a non-authenticated user uses a > > generic view (create/update/delete), they will get a failure if the > > messages framework is not installed. This is a big backwards > > incompatibility. > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
On Tue, Dec 1, 2009 at 4:35 PM, Luke Plant wrote: > I just converted some code, and the API seems good to me. I had one > issue, which was the fact that I had some code which only had access > to the User object, and not the request object, which had to be re- > plumbed. The only place this change will be an issue is where it is > difficult to do that (e.g. if your code is being called from somewhere > else which you can't change). There is no reason this should hold us > back - storing messages on the User is really a hack, and if people > have a problem with not being able to do it any more (i.e. in Django > 1.4), they can use other hacks like storing the request in threadlocal > storage. > *gasp* Did I really just hear a core committer condoning threadlocals? Storing messages on the user was bad, but not that bad. :) > The simplest solution is to catch the exception in the generic views. > Another option is to add a 'fail_silently' keyword argument, > defaulting to False, like the mail sending API. It would need to be > added to all the shortcut functions, and used in the generic views and > anywhere that you cannot rely on there being a current authenticated > User. Docs should include something about it being intended for re- > usable apps. > Good catch. fail_silently sounds good to me. I'll add. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
Latest patch, including fail_silently, is up for review: http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-e4da706e1152.diff Cheers, Tobias 2009/12/3 Tobias McNulty > The simplest solution is to catch the exception in the generic views. >> Another option is to add a 'fail_silently' keyword argument, >> defaulting to False, like the mail sending API. It would need to be >> added to all the shortcut functions, and used in the generic views and >> anywhere that you cannot rely on there being a current authenticated >> User. Docs should include something about it being intended for re- >> usable apps. >> > > Good catch. fail_silently sounds good to me. I'll add. > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
It's also a good thing, I realized last night, because it means one can use messages from a reusable app without requiring that all projects using the app enable messages. Cheers, Tobias Sent from a mobile phone, please excuse any typos. On Dec 3, 2009 6:25 AM, "Russell Keith-Magee" wrote: On Thu, Dec 3, 2009 at 2:39 PM, Alex Gaynor wrote: > On Thu, Dec 3, 2009 at ... That was a late change. There are two reasons behind it: Firstly, there is a backwards compatibility problem. Legacy code won't have the messages attribute on request, because it won't have the messages middleware. Earlier versions of the code had a 'compat_add_message' function that had a fallback to using request.user.message_set if request.messages wasn't available. However, this would have meant introducing a function in 1.2 that was deprecated at time of introduction - we would have needed to change code in 1.2 to use the compatibility function, and change it again when 1.4 came around. I suggested that the compatibility function could actually be the normal interface. That way, when 1.4 comes around, we can just update the implementation of the 'add_message' function to remove the deprecated code path. The second reason is architectural. Using messages.info(request, msg) decouples the process of sending messages from the message store on the request itself. If we ever chose to change the way the message store works, we're not bound to maintaining a request.messages data structure. I will admit that this second reason smells a little of YAGNI. I have no idea what change would necessitate decoupling the message store from request (other than the obvious reverse case of the backwards-compatibility function). The backwards compatibility issue is the primary reason for the change; the architectural reasoning is very much "after the fact". Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" g... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
On Thu, Dec 3, 2009 at 9:18 AM, Waylan Limberg wrote: > Looking though this patch I couldn't help but notice the new > get_messages function. What if a project has neither the > MessageMiddleware nor the contrib.auth app enabled? Sure a reusable > app could catch the error, but that error will change once all support > for user.messages are removed in 1.4. Shouldn't the call to > user.get_and_delete_messages be wrapped in a check that request.user > exists like the new add_message function does? > It already does: http://bitbucket.org/tobias.mcnulty/django-contrib-messages/src/e4da706e1152/django/contrib/messages/api.py#cl-38 get_and_delete_messages on AnonymousUser just returns an empty list: http://bitbucket.org/tobias.mcnulty/django-contrib-messages/src/e4da706e1152/django/contrib/auth/models.py#cl-370 IIRC this matches the behavior of the previous implementation. Am I missing something? <http://bitbucket.org/tobias.mcnulty/django-contrib-messages/src/tip/django/contrib/messages/api.py#cl-38> Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
Is there a page where one can find a quick summary of the proposed API? I have some concerns about implementing partitioning through the admin, but I expect there's something I'm missing. For those who haven't been, following the conversation closely it'd be nice to have a quick way to come up to speed. Sent from a mobile phone, please excuse any typos. On Dec 4, 2009 9:30 AM, "Russell Keith-Magee" wrote: On Fri, Dec 4, 2009 at 10:18 PM, Nan wrote: > >> 1) Ignore the problem. Admin w... This is also a possibility. Describing databases at the level of the ModelAdmin is really only useful for the partitioning case (i.e., auth models on database X, myapp models on database Y), but that is a use case we are trying to hit. It shouldn't be to hard to have ModelAdmin derive using from the site if it isn't defined locally. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" g... -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
The very first "Requirement"/ideal feature on the wiki page reads:
"Different models/applications living on different databases, for
example a 'blog' application on db1 and a forum application on db2.
This should include the ability to assign a different database to an
existing application without modifying it, e.g. telling Django where
to keep the django.contrib.auth.User table. "
That sounds perfect - having a way to modify in what database a table
exists on a per-model or per-app basis, without making any changes to
the app itself (so I can choose to put reusable app A in database X
and reusable app B in database Y).
I don't see anything in the docs about if and how this type of
partitioning is supported. From what I understand, it has been
proposed that this be implemented for the admin specifically through
ModelAdmin and/or at the admin.Site level, because in the current
iteration of the code there is no way to use the admin for anything
other than the default database.
To me, specifying the database in the ModelAdmin or admin.Site seems
arbitrary and potentially limiting: For any reusable app on the
market, depending on the value of a particular setting in your urls.py
or admin.py file is a Bad Idea. What if the admin was instead fixed
by providing facilities for the more general case outlined above?
What would this look like? I'm picturing another setting (bleh) that
maps apps and/or models to specific databases. Name choices aside,
this might look something like:
DATABASE_USING = {
'django.contrib.auth': 'default',
'myapp': 'database1',
'myapp2': {
'Model1': 'database2',
'Model2': 'database3',
}
}
The admin could automatically take advantage of this setting to
determine what database to use for a given model.
Cheers,
Tobias
On Fri, Dec 4, 2009 at 10:47 AM, Russell Keith-Magee
wrote:
>
> On Fri, Dec 4, 2009 at 11:40 PM, Tobias McNulty
> wrote:
> > Is there a page where one can find a quick summary of the proposed API?
> >
> > I have some concerns about implementing partitioning through the admin, but
> > I expect there's something I'm missing.
> >
> > For those who haven't been, following the conversation closely it'd be nice
> > to have a quick way to come up to speed.
>
> The proposed API is intentionally simple - QuerySets gain a .using()
> modifier that lets you direct a query at a specific database; save()
> gains a using argument to let you save to a specific database. There
> are some configuration changes and to the get_db_prep_* method on
> Field to support multiple database setups, but that's about it. Most
> of the changes have been in the internals to make the two external
> APIs possible.
>
> As noted a couple of messages back, support in the admin was an
> oversight. The existing admin will work for the default database, but
> will require modifications to support other databases.
>
> For more details, the links I gave in the original call for testing
> are probably your best bet:
>
> http://code.djangoproject.com/browser/django/branches/soc2009/multidb/docs/topics/db/multi-db.txt
>
> http://code.djangoproject.com/browser/django/branches/soc2009/multidb/docs/releases/1.2.txt
>
> Yours,
> Russ Magee %-)
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Fri, Dec 4, 2009 at 3:03 PM, Paul McLanahan wrote: > On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor wrote: >> We will not be adding a setting to pin an application/model to a >> specific database. We have already removed the Meta.using option. If >> you want to pin an application to a specific database it's fairly >> trivial to add a manager and override the save() method to use a >> specific DB. Our goal is to design a good long term API for having a >> flexible way to define exactly what DB any query goes to, and I >> personally have no interest in seeing short term stopgap APIs >> implemented. > > That's fine for apps under my control, but this leaves us without a > way of dealing with 3rd party apps outside of an unfortunate amount of > monkey patching. I certainly don't want the API to be "sort term" or > "stopgap", but I do want this ability. I don't see any other way to > accomplish a heterogeneous admin or partitioning of 3rd party apps. I > know and agree with the reasons that the Meta.using option was > removed, but it wouldn't have solved these issues either. Adding a key > to the DB configs may not be the right way, but I'm sure there is a > good way to accomplish this. Agreed. I was just writing basically the same reply. And in our defense, support for this functionality is the first thing one sees in the "Requirements" section on the Multi DB support wiki page: http://code.djangoproject.com/wiki/MultipleDatabaseSupport#Requirements I see nothing "short term" or "stopgap" about this; rather, it solves a specific and potentially common use case for multidb support in an elegant, extensible way that also fixes other issues with the current implementation (namely, the admin). That said, figuring out the right way to implement it is still up in the air. I proposed a separate setting; Paul proposed one integrated with the DATABASES setting. There are likely better ways to do it and I'm not attached to any particular one, but the functionality is key. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
AFAICT adding a setting for the default manager just doesn't work because then any models with custom managers either (a) would lose their custom manager, or (b) wouldn't get the manager with using(). Cheers, Tobias On Fri, Dec 4, 2009 at 3:42 PM, Yuri Baburov wrote: > Hi all, > > Database -> Model.Manager -> Queryset. > Save -> Model -> Database > > How about making a default Manager that's now "model.Manager" to be a > setting to override? > Like, calling current Manager a DefaultManager, and making "Manager = > load(settings.MODEL_MANAGER) or DefaultManager". Or > Manager.get_queryset calling customizable method. Any. > > And provide with django few most usable enhanced managers replacements. > This will solve both master/master, master/slave sharding and "this > table is at DB1, that is at DB2" use case (how to name it in a single > word?). > There should also be such general solution for complex model save > override. Maybe, Or Model.save calling such customizable method. > > Alex, you just don't get it seriously yet. Imagine the following: > In your project, you use the plugin application A written by other > people (and 25 other plugins B, C, D, ..., Z!). > It defines model A, and 3 views, each one use model A, with some > forms, templates, etc. > How are you going to change A.save and managers while keeping the views > working? > Monkeypatch it? Make patched version for each app? Well, then please > provide a method which will do this override for all models if called > from a single place in project, probably, settings. > > In large projects, single point of override on per-project basis is > required, not per-model. > > On Sat, Dec 5, 2009 at 2:12 AM, Tobias McNulty > wrote: > > On Fri, Dec 4, 2009 at 3:03 PM, Paul McLanahan > wrote: > >> On Fri, Dec 4, 2009 at 2:48 PM, Alex Gaynor > wrote: > >>> We will not be adding a setting to pin an application/model to a > >>> specific database. We have already removed the Meta.using option. If > >>> you want to pin an application to a specific database it's fairly > >>> trivial to add a manager and override the save() method to use a > >>> specific DB. Our goal is to design a good long term API for having a > >>> flexible way to define exactly what DB any query goes to, and I > >>> personally have no interest in seeing short term stopgap APIs > >>> implemented. > >> > >> That's fine for apps under my control, but this leaves us without a > >> way of dealing with 3rd party apps outside of an unfortunate amount of > >> monkey patching. I certainly don't want the API to be "sort term" or > >> "stopgap", but I do want this ability. I don't see any other way to > >> accomplish a heterogeneous admin or partitioning of 3rd party apps. I > >> know and agree with the reasons that the Meta.using option was > >> removed, but it wouldn't have solved these issues either. Adding a key > >> to the DB configs may not be the right way, but I'm sure there is a > >> good way to accomplish this. > > > > Agreed. I was just writing basically the same reply. And in our > > defense, support for this functionality is the first thing one sees in > > the "Requirements" section on the Multi DB support wiki page: > > > > http://code.djangoproject.com/wiki/MultipleDatabaseSupport#Requirements > > > > I see nothing "short term" or "stopgap" about this; rather, it solves > > a specific and potentially common use case for multidb support in an > > elegant, extensible way that also fixes other issues with the current > > implementation (namely, the admin). > > > > That said, figuring out the right way to implement it is still up in > > the air. I proposed a separate setting; Paul proposed one integrated > > with the DATABASES setting. There are likely better ways to do it and > > I'm not attached to any particular one, but the functionality is key. > > > > Cheers, > > Tobias > > -- > > Tobias McNulty > > Caktus Consulting Group, LLC > > P.O. Box 1454 > > Carrboro, NC 27510 > > (919) 951-0052 > > http://www.caktusgroup.com > > > > -- > > > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > > To post to this group, send email to django-develop...@googlegroups.com. > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > .
Re: Multiple database support: Request for feedback and testing
On Sat, Dec 5, 2009 at 8:58 AM, Russell Keith-Magee wrote: > As best as I can make out, you're addressing the problem that I've > said we aren't addressing - that of presenting a useful end-user API > for tasks like master/slave. If I'm mistaken, feel free to correct me > - preferably with some sample code to demonstrate what you're talking > about. Yes - it sounds to me like Waldemar might be talking about the "registration/callback API to allow you control database assignment on a per-query basis" that you mention above. I hadn't thought about this before, but I like the idea and I think it'll be crucial in implementing some of the more complex partitioning cases. It seems like it'll be necessary in addition to some sort of settings-based map of what apps/models go in what databases. Quick question: will the admin.Site method be useful in addition to whatever more global method we come up with for designating what tables go in what databases, or will it be obsolete (and potentially deprecated) at that point? I can't see a reason that one would want to modify the database(s) the admin uses irrespective of the global settings. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Multiple database support: Request for feedback and testing
On Sat, Dec 5, 2009 at 10:51 AM, Russell Keith-Magee wrote: > > I don't grant that proposition at all. The admin interface serves as a > working example demonstrating that you don't need to use settings to > define the way models are used. > Okay. Do you grant the proposition that "we will (not necessarily in Django 1.2) need a project-level way to specify the default database(s) to use for queries to a given model," whether it is settings-based or not? At this point, I'm prognosticating because I haven't actually written > any code for this - but I don't think the using argument to Site() > would necessarily have to be deprecated. In a single-database admin, > the using argument tells you exactly which database is to be used; if > we update admin to have a fully multi-db interface in the future, the > value of the using argument could easily be interpreted as the > "default" database that is displayed. Maybe I'm just being obtuse, but there are a couple issues with the admin approach to which I can't see a resolution yet: * Assuming the above proposition is true, the behavior of the API when the global and admin-level configurations conflict is not at all intuitive * It seems like confining every admin site to a single database would lead to needless partitioning of the admin interface for what might otherwise be a single, cohesive site. Simon's idea seems like a reasonable (and already supported?) workaround for those who need to modify the admin to use a different database in specific cases. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
On Sat, Dec 5, 2009 at 8:40 AM, Russell Keith-Magee wrote: > * Why have all the tests migrated to the Django system tests? This is > a contrib app - the tests should be internal to the app. They were moved to facilitate inclusion of a more complete test suite with a test urls.py and views.py that make sure all the plumbing works together. In short, I wanted a way to make use of the test Client without including the dummy code in the distribution. I think it has also been discussed elsewhere; that some would prefer not to deploy the tests with the production application - one more reason to keep them in 'tests' instead of in the contrib app. >From what I can tell, this seems to be in line with what some of the other contrib apps are doing, such as admin and comments. > * I'd rather the AddMessageFailure have a more generic name (like > MessageFailure). I don't see any need to be task specific in the > exception class name. Sounds good - changed. > * I don't know why I didn't pick this up earlier, but the emerging > convention for pluggable backends is for the user to specify the name > of the module, and for the module to have a predictable class name. > i.e - each storage backend module should have a "StorageEngine" class, > and the user specifies the name of the module. There is also an > emerging convention to call the pluggable bits 'backends', rather than > picking a name like 'storage'. Net result: the user should be > configuring MESSAGE_BACKEND="django.contrib.messages.backends.user_messages" > rather than > MESSAGE_STORAGE = > 'django.contrib.messages.storage.user_messages.LegacyFallbackStorage' Really? Files definitely seem to be more on the "storage" side of things: http://code.djangoproject.com/browser/django/trunk/django/core/files/storage.py > * The cookie backend is still doing a conditional import for json. The > django.utils.simplejson module already does this conditional import > check. Whoops, thanks. Removed it for real this time. :) > The rest of my notes are minor documentation fixes: > > * The documentation for the message settings that modify old settings > (MIDDLEWARE_CLASSES, TEMPLATE_CONTEXT_PROCESSORS) should have a > ..versionchanged note to indicate that they have changed in 1.2. This > has been done in the template API docs, but not in settings.txt. Added. Also added a ..versionadded in the middleware ref. > * The deprecation note in topics/auth.txt says the new messages > framework should be used "whenever possible". This makes it sound > optional, when it isn't. Updated, thanks. > * The explanatory note in "Configuring the message engine" in the > message docs isn't required - or at least, isn't required until > *after* you have described the fact that storage backends are > configurable. Removed. > * The markup for the note about using standard message levels in > reusable apps should be marked up using ..note:: syntax, so it is > rendered as a breakout box. Fixed, thanks. > * The explanatory note about overriding MESSAGE_LEVEL should be marked > up as an ..admonition:: , and should probably have an example to show > the correct technique. Good call, added, thanks. Other than the question about renaming storage -> backend I think we are close to prime time. Let me know what you think. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
setting, so it also makes > sense for it to be short and lower case. > > As for the e-mail and session subsystems, IMO they are using the less > preferable convention. Some of the disadvantages mentioned above don't > exist for the e-mail backends, because they don't use each other like > the messages ones do. > > Regards, > > Luke > > -- > "Idiocy: Never underestimate the power of stupid people in large > groups." (despair.com) > > Luke Plant || http://lukeplant.me.uk/ > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
Outstanding question regarding storage/backend notwithstanding, I uploaded a new patch here: http://code.djangoproject.com/attachment/ticket/4604/django-contrib-messages-6399c12d1773.diff Luke, it includes a note that fail_silently only hides the error when messages is disabled. I'm going to give this a final whirl by converting a project or two. Cheers, Tobias On Sat, Dec 5, 2009 at 2:05 PM, Tobias McNulty wrote: > It looks like I mis-read the original question about storage vs. > backend, so thanks for picking this up Luke. > > I don't have much to add to your argument except to say that it would > be non-trivial to move to a more strictly organized/named setup. > > Cheers, > Tobias > > On Sat, Dec 5, 2009 at 12:51 PM, Luke Plant wrote: >> On Saturday 05 December 2009 13:40:40 Russell Keith-Magee wrote: >> >>> * I'd rather the AddMessageFailure have a more generic name (like >>> MessageFailure). I don't see any need to be task specific in the >>> exception class name. >> >> Another thing here we should think about: at the moment, fail_silently >> only silences the error for the messages framework not being >> installed. But there are a lot of other ways the messages backend >> could potentially fail. Should we silence those errors too? I would >> suggest not, or there should be a separate keyword argument for that. >> But this should be clear in the docs. >> >>> * I don't know why I didn't pick this up earlier, but the emerging >>> convention for pluggable backends is for the user to specify the >>> name of the module, and for the module to have a predictable class >>> name. i.e - each storage backend module should have a >>> "StorageEngine" class, and the user specifies the name of the >>> module. There is also an emerging convention to call the pluggable >>> bits 'backends', rather than picking a name like 'storage'. Net >>> result: the user should be configuring >>> MESSAGE_BACKEND="django.contrib.messages.backends.user_messages" >>> rather than >>> MESSAGE_STORAGE = >>> 'django.contrib.messages.storage.user_messages.LegacyFallbackStorag >>> e' >> >> Hmm, it is 'emerging' only in that several established subsystems use >> it (db, session, cache) and the e-mail stuff just added uses this >> convention. There are other established conventions in the code base, >> some of which are more recent IIRC: >> >> * that used by the file storage classes, file upload handlers and the >> authentication backend where the specific class is referred to. >> * that used by the template loaders, where the specific callable >> is referred to. >> >> I actually much prefer the explicit naming of a class/callable. Here >> are some arguments in favour of this method, some of which are >> stronger than others: >> >> * you can put multiple backends in one file if you want to, and you >> are not forced to duplicate imports or get creative with module >> names if you happen to have several backends that really belong >> in the same module. >> >> * it is much more obvious for someone who does not know the code, >> since it doesn't rely on a convention of a class with a certain >> name. If they see the setting for MESSAGE_STORAGE pointing to >> a class, they will immediately know where the implementation is, >> whereas if it points to a module and the module contains multiple >> classes, they will have to guess which class is the main one, or >> browse docs/source code. >> >> * it makes it less verbose and confusing if one backend refers to >> another (as happens with messages), because all the classes >> have different names, rather than having the same name. We >> currently have: >> >> from django.contrib.messages.storage.fallback import FallbackStorage >> ... >> class LegacyFallbackStorage(FallbackStorage): >> storage_classes = (UserMessagesStorage,) + >> FallbackStorage.storage_classes >> >> which would need to be changed to: >> >> from django.contrib.messages.backends import fallback >> ... >> class StorageEngine(fallback.StorageEngine): >> storage_classes = (UserMessageStorageEngine,) + >> fallback.StorageEngine.storage_classes >> >> or, using 'as' for the import: >> >> from django.contrib.messages.backends.fallback import StorageEngine \ >> as FallbackStorageEngine >> ... &
Re: Session/cookie based messages (#4604)
On Sat, Dec 5, 2009 at 10:24 PM, Russell Keith-Magee wrote: > However, I'm also willing to admit that personal preference is a > factor here. We may just need to push this up for a BDFL judgement. I > would certainly prefer module level definitions, but at the end of the > day, I don't think I'd lose much sleep if the decision went the other > way. Pending BDFL judgment, of course, I'll offer another opinion to the mix: Given that (a) there seem to be good arguments for both sides; (b) personal preference may be a factor; (c) Django currently does it both ways without a clear choice between one or the other; and (d) the messages patch has already gone through multiple phases of polish and is otherwise ready to commit, it seems to me that this discussion, if it's worth having, ought to be taken up independently of this patch. There's been an extended period of discussion and feedback on the messages API and the MESSAGE_STORAGE setting itself has already been (albeit briefly) discussed: http://groups.google.com/group/django-developers/browse_thread/thread/eba93088c649022b/db0206eadd1a5f3d?#db0206eadd1a5f3d I'll hazard a guess that if the Django project is going to make a concerted effort at standardizing the way all the different backends are organized, it's going to take the input of far more than two core developers and a lot more time than we have before the 1.2 feature freeze. I'm suspicious that this decision falls under "whoever builds the bike shed gets to paint it," but personally I have no issue with either method--both seem to function perfectly well--and, if a consensus is reached, I'll be happy to update the messages code (if it needs to change) at that point. There would be backwards compatibility issues to deal with, but that's an issue the project will have to take on in a much larger way regardless when/if backend standardization becomes an established goal. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Conventions around plugable backends
Just wanted to add that the decision need not go either way; one possible solution would be to leave it up to the implementation and live with both conventions in the core. Sent from a mobile phone, please excuse any typos. On Dec 7, 2009 7:17 AM, "Russell Keith-Magee" wrote: Hi all (and especially Jacob), So - this is a call for any interested parties to express their opinions, followed (hopefully quickly) by a BDFL judgement. For those that haven't been following the the django-dev discussion around ticket #4604: session-based messages are nearing trunk ready status. After a few rounds of review, the implementation looks good, and the documentation is good. However, there is one sticking point left, and it's almost entirely cosmetic: how should we be referring to the configurable messaging backend in settings? The current code points explicitly at the class that implements the messaging interface: MESSAGE_STORAGE = 'django.contrib.messages.storage.user_messages.LegacyFallbackStorage. In a review note, I commented that there is an alternate trend in Django's source tree - that is to use the module as the configuration point: MESSAGE_STORAGE = 'django.contrib.messages.storage.user_messages' It is then assumed that the module provides a standard interface - e.g., a backend must provide a class called "StorageEngine". I suggested that the latter form (module-based configuration) was the emerging trend in Django backends, as it is followed by core.cache, core.db, contrib.session, and core.email, and the messaging backend should comply to that trend. Luke has contested the assertion that this is an emerging trend, and has expressed a preference for class-based configuration. The arguments both ways are covered in the recent messages on the #4604 threads (pointer into the discussion here [1]; the issue in question starts here [2]). [1] http://groups.google.com/group/django-developers/browse_thread/thread/eba93088c649022b/7b78cc341132061f [2] http://groups.google.com/group/django-developers/msg/952b97d82b126075 Here's my attempt at summarizing the arguments each way: Class-based configuration: -- * You can put multiple backends in one file if you want to, and you are not forced to duplicate imports or get creative with module names if you happen to have several backends that really belong in the same module. * It doesn't rely on a convention of a class with a certain name. If the user sees the setting for MESSAGE_STORAGE pointing to a class, they will immediately know where the implementation is, whereas if it points to a module and the module contains multiple classes, they will have to guess which class is the main one, or browse docs/source code. * It makes it less verbose and confusing if one backend refers to another (as happens with messages), because all the classes have different names, rather than having the same name. * It allows the user to structure their backend code however they want, unlike module-based configuration which is opinionated about code structure in a way that isn't obviously good to all observers. * The approach is consistent with file backends, template loaders, plus the specification of context processors, middleware, test runners, and the CSRF error view. Module-based configuration: --- * The aesthetic of user-configuration options is cleaner because configuration items are shorter and don't require duplication of terms. e.g., django.core.cache.backends.locmem.LocMemCacheBackend duplicates the 'locmem' bit for no real end-user gain unless you're planning to have a non-locmem backend in the locmem package. * The 'multiple backends in a single module' argument is arguably a false economy, as we should be encouraging code be modular, especially at the level of something like a backend which is by definition a concern that can be separated (after all, as Tim Peters said: Namespaces are one honking great idea -- lets do more of those). * Most end users aren't going to be writing message/cache etc backends, and if they are, they are hopefully talented enough to read documentation to find the convention, or at the very least, spot an obvious pattern in code. * Module based-backends allows for backends to be more than a single class - e.g.,the database backend, which is actually several classes. This also highlights the fact that backends are often more than just a single class - they are a package of data structures, support utilities, etc. A backend is a group of capabilities, not just a single class. * It's the approach used by db, cache, session, and email backends. * Context processors, middleware, test runners and the CSRF error view are by definition single classes or views, not really plugable backends. I hope I've done a reasonable job of summarizing the two positions in an unbiased way. This isn't just an argument about #4604, though. This issue also has a wider impact on the 1.2 release. T
Re: Sprint issue tracking / triaging
On Mon, Dec 7, 2009 at 6:31 PM, Russell Keith-Magee wrote: > I was thinking more of having one person at the sprint to take the > role of integrator - that is, the patches still go up on trac, but one > trusted person at the sprint takes the role of lieutenant for the > sprint, and selects patches that they consider trunk-ready. The end > deliverable is a branch that a core developer could theoretically just > git merge and push to SVN. In practice, there will probably be further > review by the core, but the idea is to provide a single rich vein of > high quality patches. Yes, personally I don't see the need to be overly organized about branching for each feature developed at the sprint. There's no need to dictate what version control system, if any, participants use to develop code for Django. Some prefer git, some hg, and some small tickets might not need a branch at all. The role of integrator does sound like a good one, though, both in terms of making sure things work (and work together) and also for keeping track of what actually gets done at the sprint. Simply merging that branch directly into trunk sounds a little dicey, however, as commit granularity in terms of features (even small bug fixes) is usually a Good Thing. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django 1.2 progress assessment
On Mon, Dec 7, 2009 at 4:59 PM, Jacob Kaplan-Moss wrote: > Additionally, a few features are in or close to last-call stage > (multidb and the smarter if tag). You can add the messages framework to the list of features that will be in Real Soon. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
I'm wondering if we should remove LegacyFallbackStorage and merge its functionality into FallbackStorage. If anyone manually settings MESSAGE_STORAGE = '...LegacyFallbackStorage', his or her code will break in 1.4. It's not a big issue, as most folks are likely to leave this setting untouched unless they want to change it to something other than the default (and all the other options don't present this backwards compatibility issue). And, the docs say this storage will be removed in 1.4. Still, something to think about, and it'd be a trivial change at this point. Thoughts? Tobias On Mon, Dec 7, 2009 at 7:25 AM, Russell Keith-Magee wrote: > On Mon, Dec 7, 2009 at 3:05 AM, Tobias McNulty wrote: >> On Sat, Dec 5, 2009 at 10:24 PM, Russell Keith-Magee >> wrote: >>> However, I'm also willing to admit that personal preference is a >>> factor here. We may just need to push this up for a BDFL judgement. I >>> would certainly prefer module level definitions, but at the end of the >>> day, I don't think I'd lose much sleep if the decision went the other >>> way. >> >> Pending BDFL judgment, of course, I'll offer another opinion to the mix: >> >> Given that (a) there seem to be good arguments for both sides; (b) >> personal preference may be a factor; (c) Django currently does it both >> ways without a clear choice between one or the other; and (d) the >> messages patch has already gone through multiple phases of polish and >> is otherwise ready to commit, it seems to me that this discussion, if >> it's worth having, ought to be taken up independently of this patch. > > I've just started a separate thread to get a BDFL judgement on this > issue. Don't worry about this stalling the #4604 effort - I'll make > sure we get a decision one way or the other, so we can get this patch > into trunk for 1.2. > > Russ %-) > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Session/cookie based messages (#4604)
On Fri, Dec 11, 2009 at 9:56 PM, Russell Keith-Magee wrote: > I actually contemplated this when I did my first review. > > On the one hand, I'm not crazy about introducing code as part of a > feature that is already on a deprecation path. On the other hand, the > alternative is to merge the two fallback stores, and remove the first > fallback mode (i.e., user-based messages) at some point in the future. > > Ultimately, I convinced myself it would be better to go with a > standalone legacy backend. Users need to have the ability to decide > when to downgrade their backend from LegacyFallback to Fallback; > merging the two backends will limit their ability to do this. > > You will also note that the LegacyFallback backend isn't actually > raising any deprecation warnings - yet. Here's my take on the > deprecation timeline for LegacyFallback: > > 1.2: Introduce session messages > > 1.3: user.message_set.add() starts raising full Deprecation warnings; > LegacyFallback still the default backend > > 1.4: user.message_set deprecated; LegacyFallback still the default > backend, but raises PendingDeprecation > > 1.5: LegacyFallback raises full Deprecation warnings, but default > backend is changed to Fallback > > 1.6: LegacyFallback deprecated. > > This is a fairly long timeline, and we might be able to tighten it a > little, but I think it highlights that LegacyFallback doesn't need to > be deprecated at time of addition. > > However, this is just my spin on the problem. I'm open to other > approaches if you can make a compelling case. Now that I think about it, I do like having a choice, too, since using Fallback directly is probably more efficient than LegacyFallback as it currently stands. I guess I'm a little averse to the extended deprecation plan. According to the longer plan, in 1.4, do we remove the message_set functionality from LegacyFallback (making it identical to Fallback), or do we delay the removal of message_set until 1.6 as well? For the record the docs currently state that /both/ message_set and LegacyFallback will be removed in 1.4. Why not just make LegacyFallback use message_set instead of _message_set (it used to do this but was changed at some point during the feedback process), so that it raises a deprecation warning now (since it is using deprecated code, after all)? Alternatively, since the warning may be a little obscure (the user is not using message_set directly), we could make LegacyFallback itself raise a deprecation warning. That would encourage folks to move to Fallback sooner rather than later. Thoughts? Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Buildbot failure
Hi Jacob, On Mon, Oct 26, 2009 at 11:05 PM, Jacob Kaplan-Moss wrote: > I've more or less given up and am working on pony-build instead. Watch > this space. Do you want any help with this? I'd be happy to if it'd be useful. I found your script at http://github.com/jacobian/pony-build-django Branch and go? Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: An issue with ticket system
On Sat, Sep 19, 2009 at 1:10 PM, Carl Meyer wrote: > Specifically, if you're obsessive about avoiding minor breakages, you > can try to avoid the "No newline at end of file" marker in your diffs; > pretty sure that's what causes Trac to choke. What version of Trac is code.djangoproject.com running? Supposedly this bug was fixed almost two years ago: http://trac.edgewall.org/ticket/6199 If 0.11.X, the fix could be as easy as easy_install --upgrade Trac. I did it last night on our multi-project, many-strings-attached Trac install and it was a seamless upgrade. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deprecating psycopg 1
+1 to removing the psycopg1 backend. I was just wondering if it was ever going to happen earlier today when I was creating example settings files for running the tests, and got tired of typing 'postgresql_psycopg2'. Even getting psycopg1 installed is a small PITA on any modern Linux system. I'll hold my breath in anticipation of your renaming plan, too. On Sat, Dec 12, 2009 at 8:09 PM, Jacob Kaplan-Moss wrote: > Django 1.2 ships. Users read the release notes, and notice that > psycopg1 is now deprecated and will be removed. It's still there, and > still supported, so they can upgrade quickly and not have to be stuck > on 1.1. Plus, those who care about these things can enable the PendingDeprecationWarnings if they want to. It certainly doesn't hurt and it probably helps a few folks. It's how everything else is deprecated and it makes sense. I see no reason to change the plan. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
MultipleHiddenInput outputs invalid HTML (#11843)
http://code.djangoproject.com/ticket/11843 This is a simple fix to a rather bothersome problem; if you need to do anything with those hidden inputs in JavaScript there's no way to uniquely identify them without extending the widget and creating your own render() (not to mention the fact that it's invalid HTML to begin with). Any chance we could get it committed soonish? Thanks! Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Looking for python/Django developers in india
The django-developers list is for discussion related to the development of django itself. Please direct your question to the django-users list. Cheers, Tobias On Mon, Dec 28, 2009 at 12:32 PM, Ravi wrote: > Hello, > > We are a hyderabad based web company and are looking for experienced > developers(at least 3+ yrs) in python/django and postgres. If anyone > interested to work on our project, Please let us know. > > Thanks, > Ravi > > -- > > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Design and code review requested for Django string signing / signed cookies
On Mon, Jan 4, 2010 at 6:00 PM, Alex Gaynor wrote:
> So, thinking out loud here, I know the DSF has a policy of hands of in
> the development of Django, but I was thinking (out loud) that perhaps
> it would be sensible for the DSF to hire someone to do a security
> audit of some of this stuff. I have 0 clue about the particulars of
> how anything like that works, but it was just a thought that occurred
> to me.
>
To be honest I prefer the distributed approach ("the more eyes the better")
of sending the code out to be reviewed by volunteers on various
security-related lists. I suppose the two could be combined, but I'd hate
to see a paid person in any way decrease the efforts of volunteers (or our
motivation to find such volunteers). Just my two cents.
Cheers
Tobias
--
Tobias McNulty
Caktus Consulting Group, LLC
P.O. Box 1454
Carrboro, NC 27510
(919) 951-0052
http://www.caktusgroup.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Message level API awkwardness
That sounds like a pretty simple addition that won't affect (m)any folks, so I'm fine with adding such a wrapper. I'd prefer the methods be called 'get_level' and 'set_level', however, so they're shorter and match the naming of 'get_messages'. Others? On Wed, Jan 6, 2010 at 6:09 PM, Jeremy Dunck wrote: > I realize I'm very late giving feedback on the API, sorry and feel > free to ignore if I'm too late. > > That said, from the docs, the API to set the effective messaging level > is awkward: > > == > # Change the messages level to ensure the debug message is added. > messages.get_messages(request).level = messages.DEBUG > == > > To *set* the messaging level, I call .get_messages? > > I think I understand the reason this was done-- get_messages is > backend- and request-specific, but it is definitely surprising. > > Perhaps something like this would do better? > > messages.effective_level(request) => messages.INFO > messages.set_effective_level(request, messages.DEBUG) > ? > > Behind the scenes, it could be almost the same implementation. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Fri, Jan 8, 2010 at 8:36 AM, Honza Král wrote: > I just hate the name save(commit=False) when it has nothing to do with > saving or committing, it just DOESN'T call save, it's imho misleading. > I understand why that is and how it came to be, I just don't like it. > I wasn't, however, proposing we get rid of this feature, just that we > extract it to a separate method or just tell people to use > form.instance (which is all what it does + creating save_m2m which can > be put elsewhere). > There is /a lot/ of code that relies on this naming and, while it might not be the greatest name choice in the world, it's one you get used to after making use of it time and time again. I'm fairly certain the 'commit' argument is not the only instance of imperfect naming in the Django core, and fixing all of these would leave Django users with a relatively insurmountable quantity of deprecated code. Frankly I'm not sure it's worth it. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Fri, Jan 8, 2010 at 4:03 AM, James Bennett wrote: > On Thu, Jan 7, 2010 at 10:40 AM, Honza Král wrote: > > ModelForm has a save() method that saves the model. It is reasonable > > to assume that if the form is valid, the save() method call should > > succeed, that's why the entire model is validated. > > Actually, I can see a strong argument against this: if I've defined a > form class that I think constructs valid instances, and it doesn't, > that's a bug in my form and Django should be making this as clear as > possible. > > Of course, the flip side is that the bug in my form may be something > subtle which breaks a constraint specified at the Python level but not > at the DB level, and so the additional automatic validation could be > the only way to catch it. > For another alternative still, a constraint may exist at the database level that Python doesn't know about (or may not be able to enforce efficiently). I regret and apologize that I'm arriving to this thread rather late. Is there a document somewhere that discusses, or could someone describe, how model validation fits between the existing form validation in Django and constraints that are specified on the database side? I too would opt for an implementation that makes model validation optional, i.e., a call that developers must explicitly make, if they choose, before saving a model. I've always been and I continue to be wary of trying to implement data constraints at the application level; that's something good relational databases have been doing and improving upon for a long time and I have little faith in my own capacity to reproduce or replace such functionality. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Model validation incompatibility with existing Django idioms
On Sat, Jan 9, 2010 at 7:46 AM, Ivan Sagalaev wrote: > I too would opt for an implementation that makes model validation optional, >> i.e., a call that developers must explicitly make, if they choose, before >> saving a model. >> > > I'm +1 on some way of validating a form without *fully* validating a model. > But for a bit different reason that I didn't see in this thread yet. > I don't see why model validation should be bound up with forms at all. The current release notes for model validation state that it won't be done unless explicitly requested by the developer, and it seems that validating the model inside a form (whether fully or partially) breaks that contract. Again - pardon my ignorance if there's something that I'm missing. I was just alarmed to find a thread about forms + model validation given the current state of the release notes. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Porting Django to Python 3
I am by no means an expert on the matter, but I remember seeing a comment awhile back suggesting that it generally makes more sense to fix the 2to3 script than to maintain two branches of the same library. Might that be the case here as well? Sent from a mobile phone, please excuse any typos. On Jan 12, 2010 11:53 PM, "Joshua Partogi" wrote: On Jan 9, 1:02 pm, Russell Keith-Magee wrote: > On Sat, Jan 9, 2010 at 2:25 AM, Dave wrote: > > Hello everyone, > > > My name... Russ, Would it be possible if the django core developers to create a python3 branch in the django svn repository? Kind regards, -- http://jobs.scrum8.com | http://twitter.com/scrum8 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Per application default database?
On Mon, Jan 18, 2010 at 11:04 AM, Bill Hubauer wrote: > One of the use cases that may be common for multiple database support is > being able to combine multiple Django applications that require different > databases into a single site. This is exactly what I need to do for one > project. This can be done with the new multiple database support, but it > feels heavy handed to me to require the "integrator" go through all of the > application code and insert "using" specifiers. I also get nervous to > about missing some places where it would be required. > > I've reviewed the code related to the selection of the default database and > think that it wouldn't be too hard to make it possible to do application > specific defaults to database settings. It would mostly be refactoring the > django.db.DEFAULT_DB_ALIAS constant into a function, and then deciding the > best way to allow the user to specify a default database per application in > the settings file. > > Has there been any consideration or discussion of this type of > functionality? > There has been. See: http://groups.google.com/group/django-developers/browse_thread/thread/7904c7da7cb0085f/eb5a359e30307e89?lnk=gst&q=multidb+tobias#eb5a359e30307e89 If I recall correctly, the resolution was basically "not in this phase," i.e., this is something to be worked out in a future release of Django. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Looking for full-time developer
This is not the right forum for job postings. This list is for discussion related to the development of Django itself. You might instead try the django-users list [1] or the Django Gigs web site [2]. In all honestly you will find a much larger number of actual Django developers at either of those two locations. -Tobias [1] http://groups.google.com/group/django-users [2] http://djangogigs.com/ On Mon, Jan 18, 2010 at 3:40 PM, gnoze5 wrote: > Hey there, > > I am looking for a full-time Django developer(preferably someone with > a solid python background) to work remotely or in Lisbon , Portugal. > We are currently developing several web applications in Django and > need someone to complete our team. > > I am sorry if this is inapropriate but it is not that easy to find a > good Django developer via normal HR means. > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible bug in messages framework?
Hi Jeff, Could you try again without a comma in the message and see if the CookieStorage starts working again? Either way, that definitely sounds like a bug to me. Thanks, Tobias On Fri, Jan 22, 2010 at 12:13 AM, j...@jeffcroft.com wrote: > Sean- > > Can't say for sure it's related, but I can verify that I was using > Safari (Mobile) and that my message had commas in them...so it > definitely could be. > > Switching to session storage solved the problem for me, and that > backend works fine for my needs. So, it's no longer pressing issue > for me, but there definitely seems to be something wrong in the cookie > storage backend. > > Jeff > > On Jan 21, 9:07 pm, Sean Brant wrote: > > I wonder if this is related? > http://groups.google.com/group/django-developers/browse_thread/thread... > > > > On Jan 21, 2010, at 10:55 PM, j...@jeffcroft.com wrote: > > > > > > > > > After a little more playing around, I've discovered that this is not > > > an issue if I use the session storage -- so it seems to be related to > > > cookie storage. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > > To post to this group, send email to > django-develop...@googlegroups.com. > > > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > > > For more options, visit this group athttp:// > groups.google.com/group/django-developers?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Possible bug in messages framework?
On Fri, Jan 22, 2010 at 10:45 PM, Luke Plant wrote: > On Saturday 23 January 2010 02:44:39 Luke Plant wrote: > > > BTW, further research shows that we are not really RFC 2109 > > compliant at all, but then again no-one is. It seems virtually > > everyone (server side and client side) is using 'Netscape style' > > cookies with some things adopted from RFC 2109 and RFC 2965, > > including 'max-age' and the use of quoted-string, but not the all > > important "Version" attribute which turns on RFC 2109 cookies. > > Hardly anyone is using Set-Cookie2 from RFC 2965. So specs of any > > kind are fairly meaningless here, it's a matter of what everyone > > does. > > Actually, to add a bit more: > > http://www.ietf.org/mail-archive/web/http-state/current/msg00078.html > http://codereview.chromium.org/17045 > > It's all pretty horrific, it pushes me back towards adding a layer of > quoting to our cookie handling just to try to avoid it all - but a > robust encoding which definitely avoids all problems. We should note > that the presence of semi-colons is more likely to cause problems than > commas - Internet Explorer splits on semi-colons, irrespective of > quotation marks. > Technically I imagine it is possible to come up with a way to encode all new cookies in a safe way, but still support "decoding" old-style cookies. That said, I have reservations about any kind of across-the-board encoding because it makes it necessary, when/if the cookies need to be read by JavaScript, to implement that same decode/encode on the client side. My personal preference would be to fix the messages implementation and add a note to the cookies documentation saying that it's "recommended to encode cookies to avoid potential browser bugs," and list off a few of those bugs. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: 404 debug pages should show the name of the tried urlpattern - #9310
What do we do with tickets like this? Given that this has been ready for commit since September, I emailed a reminder to the list in October, and it's such a tiny request, I find it frustrating that this won't make it in for 1.2. Personally I have no motivation to maintain the patch going forward and would rather see the ticket get marked as "wontfix" than be pushed off indefinitely. It is poor use of sprinters' time (and defeating, both personally and to the project) to work on tickets that will never make it in to trunk. I'm hoping this will spark a discussion about how we can work more efficiently and put donated time to better use. I may be a bit biased, because this is coming on the tail end of spending 2+ person hours trying to reproduce a ticket in the PyCon sprint that, I later found out, two others had done the same thing with a day earlier, but neither had indicated as much in the ticket. A couple ideas to get us started: 1) Reemphasize via documentation and/or training (and/or by reading this message) the proper work flow for tickets (e.g., accept it when you start working on it, post a comment when you're done, etc.): http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets 2) For each release, assign several people (I'd be happy to take a turn) the task of searching through all outstanding tickets in the milestone in question a couple weeks before the feature freeze and assigning "committable" ones to specific committers. Maybe this ticket is an outlier, but I expect there are others out there that are also getting missed. I'm not sure if this means that the current way ticket triage is outlined to work is just not happening, or if there are changes we need to make so that it works more effectively: http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage Cheers, Tobias On Mon, Oct 12, 2009 at 7:30 AM, Tobias McNulty wrote: > In case it's not already on someone's radar, the patch on this ticket > could use a review at some point: > > http://code.djangoproject.com/ticket/9310 > > Thanks - > Tobias <http://www.caktusgroup.com> > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django's testing infrastructure
I think this is a great move and will be an awesome resource for the community. I'm working on getting some CPU time at the OSU OSL and/or from Caktus to contribute to the effort. Cheers, Tobias On Thu, Feb 25, 2010 at 11:08 PM, Sean O'Connor wrote: > A platform we probably should get into the mix is a CentOS/RHEL 5 box. I > suspect a significant portion of the community is stuck on such boxes and > given the ancient versions of everything available under RHEL I'm sure that > there are things which will break there and not in a developer's standard > environment. > > I personally don't have a suitable RHEL box laying around but this seems > like a good candidate for either another volunteer or DSF funds. > > > Sean O'Connor > http://seanoc.com > > > > On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher wrote: > >> Hey everyone, >> >> During the sprints, I worked to set up a hudson instance for Django. This >> is hopefully going to be the way that we are going to go forward for now >> with doing continuous integration for Django. I have a pretty good setup >> going currently, and want make it really fantastic. At this point in time, >> what we really need now is some more hardware to be able to run tests on. >> >> The current setup is hosted at: http://hudson.djangoproject.com/ >> >> Currently, I have tests running on the following architectures: >> >> Django trunk: >> >> Solaris: >> Python 2.4-2.5 >> Databases: sqlite, postgres, mysql >> >> Ubuntu: >> Python 2.5-2.6 >> Databases: sqlite, postgres, mysql >> >> Django 1.1.X: >> >> Solaris: >> Python 2.5 >> Databases: sqlite, postgres >> >> This gives us pretty good coverage currently, but the whole point of doing >> CI is that we catch bugs on other platforms we wouldn't normally run on. >> >> What we need >> === >> >> So I'm looking for people who can offer other boxes that they would like >> to see tested. Currently the big ones we aren't covering are Windows boxes, >> and the Oracle backends. There are lots of other permutations that we could >> be testing against (Different python runtimes being a good example). >> >> However, we don't want to get in a situation where boxes that people have >> set up just disappear. So, I'm only currently looking for machines that >> people would be able to dedicate to the effort. We would require a >> django-testing user account on the box, with our SSH key on it. There would >> also be a team of trusted users, who would have access to this key and thus >> your machine. >> >> We want the build farm to be stable and useful, and in the past we have >> had too much trouble having machines just disappear. >> >> Requirements >> === >> >> Currently the hudson requirements seem to be about <1GB of disk space, >> with 512MB of ram. I'm also looking into some pony build/barn based >> alternatives that would knock the memory requirements down pretty >> substantially. However, for the current 1.2 release it looks like hudson is >> how we're going to make it going forward. >> >> Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so >> another way that we might be able to get this going is to be able to have >> donations to the DSF, and have them get some dedicated rackspace boxes. >> However, for now, I'm hoping that we can cobble together enough stuff to get >> 1.2 tested really well. >> >> Feedback >> == >> >> If you have any thoughts on CI, or any advice, I would love to hear it. >> I'm trying to make our Continuous Integration setup really kick ass, so >> feedback is necessary to do this. I have some notes and ideas that I have >> been recording while setting things up over at the pycon etherpad: >> >> http://pyconpads.net/django-testing >> >> Let me know if you have any thoughts, questions, or concerns. >> >> Cheers, >> Eric >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com >> . >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> > > -- > You received this message because you are subscribed to
Re: Call for sprinters for 1.2
Hi all, We're doing another Django sprint THIS WEEKEND at Carrboro Creative Coworking in the NC Triangle, for anyone in the area: http://code.djangoproject.com/wiki/Sprint201003TriangleNC Again the sprint is this weekend, March 20 & 21, from 9am to 5pm both days. Caktus will be sponsoring again with lunch both days - but more sponsors for drinks, snacks, etc. would be great. Just add your name & what you want to bring to the list on the wiki page. Everyone's welcome - if you haven't worked on Django before, a sprint is the best place to start out. Hope to see you there! Cheers, Tobias On Tue, Mar 16, 2010 at 11:08 AM, James Bennett wrote: > Russ is about to put up a post on the Django weblog with the current > state of 1.2. There's been quite a bit of progress since the last > update, but there are still around 60 tickets which will need in-depth > attention before we hit the point of releasing 1.2; the remainder of > the tickets on the milestone are mostly trivial (documentation > updates, translation fixes and other minor issues). > > To help get these tickets resolved (and 1.2 out the door), we'd like > to organize a 1.2 sprint either this weekend (March 20/21) or the next > (March 27/28), and put out a call for anyone who's willing and able to > join in. The focus will be entirely on the 1.2 milestone tickets, with > the goal of resolving as many as possible and getting to the 1.2 > release candidate. So if you're interested and would like to help out, > please head over to the wiki page for the sprint: > > http://code.djangoproject.com/wiki/1.2ReleaseCandidateSprint > > and add your name and when you'll be able to sprint. > > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Extra params + aggregation creates incorrect SQL - Ticket 11916 - Oracle issues
I just created a test for http://code.djangoproject.com/ticket/11916 The test verifies that the code fix makes the query succeed on mysql, pgsql, and sqlite. On oracle, however, not only does the new test fail, but the code fix also breaks other tests in aggregation_regress (thanks kmt for testing!). Could someone with oracle knowledge take a look at this ticket? Given that the "fix" introduces other issues in oracle backend, I hesitate to have this committed before the oracle issues are resolved. Thanks! -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
+1 Sent from my mobile device. On Jul 16, 2010 6:54 AM, "Carsten Reimer" wrote: Hello, I am not quite sure if this is the right mailinglist but as long as my remarks are about a core-component of django I hopefully chose the right list. Dealing with cache-stuff in Django I realized that it seems to be impossible to use a timeout=0 (which in terms of memcached meant that the item would never expire unless it has to make way for new items due to memory shortage). This is because even still in the most current trunk-version the timeout is calculated (in django.core.backends.memcached.CacheClass._get_memcache_timeout) as timeout = timeout or self.default_timeout where timeout is one of the parameters given to _get_memcache_timeout. So as long as timeout=0 always the default_timeout will be used. Maybe this behaviour is intended to prevent memcached being filled up with items that never expire. In my opinion it may be better to enable developers to use the timeout-values as intended by memcached (where 0 means no expiration at all). So I would like to suggest to change the default value in all method signatures of the memcached.CacheClass (and whereever it whould be necessary) from 0 to None and to replace the line above by an if-clause as if timeout is None: timeout = self.default_timeout This is not as elegant as the original version but now it would be possible to use 0 as a timeout. If it would help I can try to open a ticket and provide a first path against the current trunk. With best regards Carsten Reimer -- Carsten Reimer Web Developer carsten.rei...@galileo-press.de Phone +49.228.42150.73 Galileo Press GmbH Rheinwerkallee 4 - 53227 Bonn - Germany Phone +49.228.42150.0 (Zentrale) .77 (Fax) http://www.galileo-press.de/ Managing Directors: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker HRB 8363 Amtsgericht Bonn -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Patch: Indefinite args for simpletags and inclusion tags
On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows < stephen.r.burr...@gmail.com> wrote: > Before posting the patch to django's ticketing system, I wanted to > check whether this would be a non-trivial patch and whether there > might be any good alternatives. > Hard to tell without seeing the patch. :-) Could you stick it somewhere we can see it? Personally I like to see them in Trac, since it comes with pretty colors. If there isn't a ticket already out there for this I see no problem with creating one. We can always close it if it gets rejected. Cheers Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
The only concern in that ticket seems to be that 0 means different things for different cache backends. There may have been some effort towards making them all behave the same when 0 is passed. Personally I prefer the approach of not messing with the value at all, and passing it straight to the configured cache backend. You don't want Django messing with your .extra() or .raw(), so why should it try to magically alter the parameters you pass to your cache backend? Furthermore, correct me if I'm wrong, but: timeout = timeout or self.default_timeout seems like an oversight on the part of whoever wrote that line originally, not some intended functionality to prevent 0 from ever making it to the actual backend. Chances are, if you configured a cache backend for your Django project, you chose one explicitly and have some cognition of how it works. We could could change line this to: timeout = timeout is not None and timeout or self.default_timeout and simply add a big fat warning to the docs stating that 0 means different things on different backends. Thoughts? Tobias On Thu, Jul 22, 2010 at 7:44 AM, Will Hardy wrote: > I thought this was familiar too: < > http://code.djangoproject.com/ticket/6988> > > Is this the ticket you were thinking of? It seems to have been reopened. > > Cheers, > > Will Hardy > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Documenting new features: built-in obsolescence of the "versionadded" tag.
I agree. It's a little odd seeings things flagged "New" that have been around since 1.0. I also like your proposal of removing the notes for unsupported versions. Tobias On Fri, Jul 23, 2010 at 12:06 PM, richardbarran < richardbar...@googlemail.com> wrote: > Hi everybody, > The Django documentation places a strong emphasis on highlighting new/ > changed features with lines such as: > >"New in Django 1.0: Please, see the release notes" > > Such comments are a useful mental reminder when scanning through the > docs, they do however have one downside: built-in obsolescence. With > the passage of time (and versions), they will end up referring to long- > forgotten Django releases, and become just cruft. > My question: how long should these "versionadded" tags remain in the > documentation? My $0.02: seeing as only 1.1 and 1.2 are officially > supported, and that *in theory* everyone should already be working > with those - reminders for earlier versions e.g. 1.0 have become > cruft. > Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
On Sat, Jul 24, 2010 at 4:07 PM, Carl Meyer wrote: > It's not obvious to me why .extra or .raw are the appropriate analogy > here, instead of the rest of the ORM API, which does attempt to > present the same semantics regardless of backend. > The issue is about values passed, not about semantics. I admit, it wasn't a great analogy to begin with, but it does hold for other aspects of the ORM as well (e.g., you wouldn't want values that you set to 0 converted to None on model.save()). The argument that "you know what cache backend your project uses" does > not apply to the significant ecosystem of caching-related reusable > Django code: johnny-cache, cache-machine, cachebot, and more. > True, hence the proposed big note in the docs stating that the value 0 should be used with care. If such reusable code needs to cache things forever, which sounds perfectly reasonable to me, I'd still rather not co-opt "0" to mean "forever" in all cases. Each backend that supports caching with no timeout could easily offer a class attribute, such as "TIMEOUT_FOREVER", that indicated how to set the timeout in these cases. > Last week I uploaded a patch to #6447 that maintains cross-backend > parity of allowed cache keys (without any performance hit on > memcached) by making sure the other backends will reject the same keys > memcached will reject. You approved this approach on IRC, Jacob, so > given the discrepancy I'm just curious whether it is in fact a design > goal to have semantic parity between the backends shipped with Django. > Rejecting a particular subset of cache keys is also not the greatest analogy to co-opting configuration values. :-) Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Filebrowser functionality in contrib?
On Thu, Jul 29, 2010 at 3:32 PM, shacker wrote: > > I've been thinking that it seems like solid file management would be a > good candidate for inclusion in contrib, but wanted to put feeler out > on this list to see whether others might agree. Would this make a good > 1.3 feature? -1 For whatever it's worth, my sense is that there are a number of these types of third party apps out there, and no single one is a clear winner. Furthermore, I don't really see what adding file management to contrib gives us (it seems to work just fine as a third party app), and I'd hate to see innovation stifled at this stage by including one of the implementations in contrib. Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: memcached-based-cache - timeout=0 does not work as intended by memcached
On Tue, Jul 27, 2010 at 4:04 PM, SmileyChris wrote: > > I agree with Carl. > We have an abstracted api - having a property with different meanings > for different backends makes things a lot less pluggable. Sure. Upon closer investigation, I think this is pretty much a non-issue. My only point is that all cache backends should receive whatever timeout they're passed, unmolested by Django. Given that all the backends, besides memcache, are implemented in the Django source, I see no reason why they couldn't be modified on a case by case basis to support a "cache forever" option, indicated by timeout=0, while leaving the common code intact and without really co-opting anything. Establishing this as a loose convention seems like a reasonable enough plan to me. I will say that the memcache issue seems more like a bug, while special-casing timeout=0 for all the other backends seems more like a feature (and one that may require a lot more discussion, code, and testing relative to the 1-line memcache fix). Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Filebrowser functionality in contrib?
On Fri, Jul 30, 2010 at 1:54 AM, shacker wrote: > ... except that it's not working just fine (because of this dependency > on Grappelli). That sounds like a problem with the 3rd party app, not something that would be resolved by incorporating it in Django proper. That said, as Russell suggests, it may be possible to enhance the admin in ways that make writing third party apps like this easier. Cheers, Tobias -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: How to get patches from 'Accepted' to 'Committed'
Steve, In my experience the best approach is to open a thread on this list asking for someone to review/commit each of your tickets individually. Since all involved in the project are volunteers, it may take some work (e.g., asking a few times) on your part to raise awareness of the issue. But if you're persistent & your request is reasonable, you'll get it committed. Cheers, Tobias On Tue, Aug 3, 2010 at 10:22 AM, Stephen Kelly wrote: > Hi, > > The diagram here shows the lifecycle of a ticket. > > http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage > > What I don't get is how a ticked goes from 'Accepted' to 'Ready for > checkin' > > The context I ask in is in relation to patches I submitted a year ago and > which were accepted: > > > http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&reporter=~steveire&order=priority > > Should I change the status to 'Ready for checkin' myself or is somebody > else > supposed to? > > I'd like to contribute more small patches to Django, but I must say it's > demotivating that those haven't seen any action since being accepted, and I > couldn't see what I need to do to get those committed. If someone can tell > me what's missing that's something I can work with. > > All the best, > > Steve. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: help
André, Welcome. Please direct your questions to the python and/or django-users mailing lists. This list is for discussion related to the development of Django itself. Regards, Tobias On Tue, Aug 3, 2010 at 10:36 AM, André Asantos wrote: > I am totaly new to Python world... > > I would like to konw: > > 1- py is Python class extension? > 2-does django have any similar .jsp GUI? or is only use HTML for GUI? > 3-is netbeans IDE the best IDE? > > > André AS > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 USA: +1 (919) 951-0052 http://www.caktusgroup.com -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
