On Dec 26, 2007 5:15 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
> However, with svn, you can inline the login_required right in urls.py;
Actually that's available in 0.96 as well. And it's far better and
more flexible than trying to hard-wire a 'login_required' argument
into every generic view.
Nah, you just have to do what django itself does:
def foo(args):
# whatever
foo = login_required(foo)
That is really all the magic '@' syntax does.
On Wed Dec 26 15:05 , kevinski <[EMAIL PROTECTED]> wrote:
That is most definitely the smartest way to do it, however we are
still stuck
kevinski said the following:
> That is most definitely the smartest way to do it, however we are
> still stuck on Python 2.3 at my work. I suppose I may need to rely on
> my hack until the powers that be see fit to upgrade to 2.5 or 3.0 or
> whatever.
That changes nothing except the syntax used.
That is most definitely the smartest way to do it, however we are
still stuck on Python 2.3 at my work. I suppose I may need to rely on
my hack until the powers that be see fit to upgrade to 2.5 or 3.0 or
whatever.
On Dec 26, 4:56 pm, "Patryk Zawadzki" <[EMAIL PROTECTED]> wrote:
> 2007/12/26,
See: http://blog.michaeltrier.com/2007/12/17/this-week-in-django-2-2007-12-16
On Dec 26, 4:56 pm, "Patryk Zawadzki" <[EMAIL PROTECTED]> wrote:
> 2007/12/26, kevinski <[EMAIL PROTECTED]>:
>
>
>
> > Not sure how useful this would be to the majority, but I discovered a
> > need for user
2007/12/26, kevinski <[EMAIL PROTECTED]>:
>
> Not sure how useful this would be to the majority, but I discovered a
> need for user authentication when using the Simple Generic Views, so I
> had to add the Login_Required argument to views.generic.simple. I
> would like to recommend this tweak be
Not sure how useful this would be to the majority, but I discovered a
need for user authentication when using the Simple Generic Views, so I
had to add the Login_Required argument to views.generic.simple. I
would like to recommend this tweak be added.
from django.shortcuts import
We're using this 'hidden' feature as well, for similar reasons.
I built a search form that allows the user to select multiple parameters
to filter by. I just named the form fields using the appropriate lookup
form of the field names (for example, a form TextField named
user__first_name, etc.).
Mingers,
I have pretty much the same use case as you: I wanted the filtering in
the admin to be more "like a spreadsheet".
See the screenshot on my website to see how I solved the issue:
http://www.frepple.com/screenshots/miniadmin.png
It allows the user to enter the filter value, select a
On Dec 26, 2007 6:10 AM, Mingers <[EMAIL PROTECTED]> wrote:
> Turns out, this is already partially implemented (by accident?). From
> the admin, you can already filter rows for the list display by passing
> GET arguments, ie. /admin///?
> __gt=10&__lt=20
>
> Well, I'm a django newbie, so you all
The subject of this thread is not a question. I just try to highlight
the difficulties of third-party module creation. It's not so easy as
suggested in
http://www.pointy-stick.com/blog/2007/11/11/django-tip-external-database-backends/
--~--~-~--~~~---~--~~
You
The main problem is that I already have a working code that does all
that I have written about and a lot more. Trying to fit it to external
Django extension will take too much time and effort. So I find that it
would be better to start a new independent project based on Django.
The main advantage
On Dec 26, 2007 9:26 AM, Marc Garcia <[EMAIL PROTECTED]> wrote:
>
> No, the translations are ok, so outside the admin that translations
> are working fine. I thing it should be a problem of the admin. Has
> somebody tested that admin translations are working in the newforms-
> admin branch?
>
I
> 2. '%s' placeholders are hardcoded into Django. Existing solutions
> (like in sqlite backend) introduce the unneeded overhead in each
> database query. There are many other small things hardcoded into
> Django with Postgres in mind. Other backends has workarounds with
> added overhead and it
On Wed, 2007-12-26 at 07:10 -0800, Ivan Illarionov wrote:
> Thank you. Now I have better understanding. I agree that I was too
> pessimistic and maybe had some wrong assumptions about this stuff. I
> didn't say that Django is not production-oriented I only mean that
> it's hard to extend Django
Thank you. Now I have better understanding. I agree that I was too
pessimistic and maybe had some wrong assumptions about this stuff. I
didn't say that Django is not production-oriented I only mean that
it's hard to extend Django with alternative database keeping the same
production quality
On Wed, 2007-12-26 at 05:54 -0800, Ivan Illarionov wrote:
> Django documentation states that "For performance, (uploaded) files
> are not stored in the database" Is this really true? Research
> http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
> shows that it's more
No, the translations are ok, so outside the admin that translations
are working fine. I thing it should be a problem of the admin. Has
somebody tested that admin translations are working in the newforms-
admin branch?
On 22 dez, 23:54, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> On 22-Dec-07,
On Wed, 2007-12-26 at 04:46 -0800, Ivan Illarionov wrote:
> I would be glad if it would be possible to maintain only external
> Django backend. It's a lot easier than maintaining the whole forked
> framework. But backend solution is not really that easy:
This sort of reply is exactly why this
On Dec 26, 2007 7:54 AM, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> Django documentation states that "For performance, (uploaded) files
> are not stored in the database" Is this really true? Research
> http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
> shows that
Django documentation states that "For performance, (uploaded) files
are not stored in the database" Is this really true? Research
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
shows that it's more advantageous to store small media files (<256K)
in the database,
I would be glad if it would be possible to maintain only external
Django backend. It's a lot easier than maintaining the whole forked
framework. But backend solution is not really that easy:
1. Using very large varchars for TextFields needs a lot more than just
overriding creation.DATA_TYPES
Hi everyone,
I've been working on a problem where I'd like the admin to be able to
filter for rows based on certain conditions for the list display, i.e.
basically anything that can be used as keyword arguments in
.objects.filter(**kwargs) should be allowed as a filter for
the list display.
On Wed, 2007-12-26 at 03:38 -0800, Ivan Illarionov wrote:
> ... continued from Cache backend thread.
>
> I have a lot of working code that I know will never get into Django
> and I just can't publish it as an external project/projects because
> it modifes the core of Django dramatically. For
... continued from Cache backend thread.
I have a lot of working code that I know will never get into Django
and I just can't publish it as an external project/projects because
it modifes the core of Django dramatically. For example, I use
Firebird database. I want to use native '?'
25 matches
Mail list logo
