Re: Finding models by name

2006/2/5, Maniac <[EMAIL PROTECTED]>: > > The recent message from Luke Plant on generic views call syntax got me > thinking. Now one should pass a model's queryset into a generic view. > This means that urlconf should import all models used in generic views > which would become an annoying boilerp

Re: Finding models by name

Maniac wrote: The recent message from Luke Plant on generic views call syntax got me thinking. Now one should pass a model's queryset into a generic view. This means that urlconf should import all models used in generic views which would become an annoying boilerplate if you use them extensi

Finding models by name

The recent message from Luke Plant on generic views call syntax got me thinking. Now one should pass a model's queryset into a generic view. This means that urlconf should import all models used in generic views which would become an annoying boilerplate if you use them extensively. Another u

Bug report[magic removal]:'Post' object has no attribute 'get_tag_list'

I'm using the lastest svn magic-removal branch code, but as I test a blog project, I'v gotten an exception when I adding a post in admin: Exception Type: AttributeError Exception Value:'Post' object has no attribute 'get_tag_list' Exception Location: c:\python24\lib\site

Re: still some magic left in magic removal

>But have you tried getting the >above to work with magic-removal? It doesn't work for me (i.e. I can >import the models with 'from appname.models import MyModel, but the >models aren't found by django admin etc), hence my other thread 'Models >in separate files'. In that case, open up a ticket

Re: Models in separate files

On Saturday 04 February 2006 00:42, Luke Plant wrote: > from someotherfile import Foo, Bar > from django.db.models import register_models > register_models(sys.modules[__name__], Foo, Bar) I've eliminated the need for this register_models() call now. I took out the whole module._MODELS thing t

Generic views and new syntax

Generic views currently have the problem that the 'extra_lookup_kwargs' is a mixture of query lookup args and thing like 'limit', 'order_by' etc. I propose we change them so that they take QuerySets instead, and remove 'extra_lookup_kwargs', and replace 'model' with 'queryset'. From my brief

using accounts to prevent ticket spam ?

Hi, I think it has become to much spam in django trac. I suggest to use http://trac-hacks.org/wiki/AccountManagerPlugin so only registered users can change stuff and comment bugs. I think this would prevent much of the spam currently comming in, or at least allows to ban those accounts. Maybe ip

Re: Django auth magic

# If you want to use LDAP or OpenID, you obviously aren't going to use # a Model for authentication. Especially not a Model which uses a SQL # schema... Actually, that all depends on how you want *external* authentication to affect *internal* accounts. It may not be enough to say that an OpenID

Re: Django auth magic

You guys are completely misintrepreting the point of this posting. It has to do with the auth MODEL. Nothing else. When you say Model, you are obviously referring to SQL. It is beyond me how you people come up with LDAP and OpenID and all these other wishes. If you want to use LDAP or OpenID, you

Re: still some magic left in magic removal

On Saturday 04 February 2006 11:12, hugo wrote: > Nobody prevents you from doing models/__init__.py and loading all > your model snippets in there - but I am really strong objected > against the framework _requiring_ such bloat. So if your app really > needs structuring models into different fil

Re: still some magic left in magic removal

Amit Upadhyay wrote: > On 2/4/06, Robert Wittams <[EMAIL PROTECTED]> wrote: > >> >>...Horrible api example deleted... > > > > Lets see. > > >>Cramming everything in a class will always force us to do some meta >> >>>programming. >> >>This has no meaning as far as I can tell. Are you seriousl

Re: speeding Django up

Good idea Victor. After a couple hours the backends got 150MB large each and the whole thing put the server down. So what I'll do is make sure the backends die after serving a couple thousand of requests. This should make me safe from such errors. I can't just ignore a 100% increase in performa

Re: still some magic left in magic removal

>I was going through magic removal wiki page, and encountered this, I think >there is still some magic left in the Custom managers, and multiple >managerssection. I have a following objections: It's maybe not perfect, but a very good start. No one prevents later refinements - we just need somethi