Hi Thomas,
Ya, it would be really nice if there was a standard way of handling
authorization for views, so that external code can check if a view is
authorized. I have been doing identically the same thing, except I was
naming the view attribute "authorized".
The current decorators could be modi
On Tue, Nov 4, 2008 at 2:58 AM, Bob <[EMAIL PROTECTED]> wrote:
> On a somewhat related note, is there some reason that 1.0.1 and 1.1
> milestones have not been created in Trac? It seems like triaging bugs
> into one of these releases should happen in Trac, not the mailing
> list.
Yes, there is a
James Bennett wrote:
> See the weblog entry:
>
> http://www.djangoproject.com/weblog/2008/oct/31/101-beta/
>
> And the downloads page:
>
> http://www.djangoproject.com/download/
>
> As previously mentioned, this is mainly a preview to let people get a
> feel for what's been fixed/improved in the 1
On Nov 3, 10:24 am, "Collin Grady" <[EMAIL PROTECTED]> wrote:
>
> I think you're confused - the context processor doesn't set a cookie,
> so it isn't causing any Vary behavior, and admin *does* currently
> depend on it - it needs the info the processor provides. Unless admin
> was rewritten to
Usage questions belong on django-users, not django-developers - this
list is for the discussion of the development of django itself.
--
Collin Grady
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developer
On Sun, Nov 2, 2008 at 8:57 AM, bo <[EMAIL PROTECTED]> wrote:
> Yes, that may be true.
>
> But why does the 'default' behavior impose these dependencies when
> they are not required? As that context processor has this other 'side
> effect' of making an entire site "Vary" under a cookie, hit the
>
On Oct 31, 5:38 am, mrts <[EMAIL PROTECTED]> wrote:
> There has been much reluctancy in letting triagers tag and prioritize
> 1.0.1 milestone tickets. Now that 1.0.1 is really close, can we
> perhaps discuss what are the things that really should be fixed before
> it is released?
>
I have patche
On Nov 3, 6:30 pm, Carl Meyer <[EMAIL PROTECTED]> wrote:
> On Nov 3, 3:24 am, Siddhi <[EMAIL PROTECTED]> wrote:
>
> > What is needed is a way for a test to specify its environment so that
> > it is run in the same environment irrespective of the project
> > environment specified in settings.py.
>
The title says it all!
[8267] added the ability to force an SQL insert (or force an update)
via a model's save() method.
I would like the same force_insert and force_update flags to be
supported in a modelform's save() method.
These flags enable better control over some edge cases - e.g.
force_
Shouldn't we have a string freeze before the 1.0.1 release (e.g. both
#8882 and #9493 bring in new error strings)?
Otherwise translators have to either continuously update the
translations as new strings land or accept that 1.0.1 is released
without complete translations.
--~--~-~--~~
On Oct 31, 5:19 pm, "Joey Wilhelm" <[EMAIL PROTECTED]> wrote:
> I would like to suggest the following:
> http://code.djangoproject.com/ticket/9245
> http://code.djangoproject.com/ticket/6710
>
> They both have fully functional patches... although granted the second has
> no tests.
IMHO http://cod
Can someone point to the correct way to do this?
Suppose i'm working in a tumblelog, it's basically , 4 o 5 tipes of
"post item" that share some cmmon information.
So the first approach i would go is:
cllass Post(models.Model):
here goes common metada of all things that can be "posted" like
I would like to nominate:
http://code.djangoproject.com/ticket/8754
http://code.djangoproject.com/ticket/9206
Both have patches which still apply, and just haven't been reviewed
yet.
Richard.
--~--~-~--~~~---~--~~
You received this message because you are subscri
On Nov 3, 3:24 am, Siddhi <[EMAIL PROTECTED]> wrote:
> What is needed is a way for a test to specify its environment so that
> it is run in the same environment irrespective of the project
> environment specified in settings.py.
This doesn't fix the third-party/contrib apps problem, but "a way fo
+1
On Mon, Nov 3, 2008 at 3:24 AM, Siddhi <[EMAIL PROTECTED]> wrote:
>
> So here is the situation:
>
> I have a middleware installed that looks at the HTTP_HOST header and
> stores the domain and subdomain into the request object. Now when
> running unit tests, the tests fail because the HTTP_HOS
So here is the situation:
I have a middleware installed that looks at the HTTP_HOST header and
stores the domain and subdomain into the request object. Now when
running unit tests, the tests fail because the HTTP_HOST header is not
passed into the test Client object. Even if I modify my own tests
16 matches
Mail list logo
