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 seriously suggesting
>>that we shouldn't even use metaclasses?
>
>
>
> Well I am not saying we shoud never use metaclasses, but putting the models
> in seperate modules has many benefits.
>
> - the module name is in not capitalized, class name is, and i am free
> to pick up the module name which might be different than class name.
> people.all() returns a list of People. people.filter(name='asd') looks
> better than Person.filter(name='asd')
> - it leaves us the option of having a single file containing all admin
> information for example, and not wading through a monolithic huge single
> model file containg all 20 of my models, or going through 20 files if i
> have
> split them.
This is actually possible AFAICT, but unlikely to be used. Eg
class Whatever(Model):
...fields...
Whatever._meta.admin = Admin(...)
the ._meta is kind of skanky I'll agree. I would prefer it if there was
a global mapping in Options, eg
Options.for_model(Whatever).admin = Admin(...)
> - it leaves us the option of having a GuiAdmin without another round
> of modifications in the django core for adding yet another GuiAdmin inner
> class.
This doesn't ever need to happen again. Read the metaclass. You can add
all kinds of stuff without modifying it using contribute_to_class and
attribute transforms (assuming that wasn't reverted...)
> - admin then becomes a really normal app.
I agree with the sentiment (not your route), but the goal of many seems
to be to shove as much special case functionality in the admin as
possible ( see the manipulators discussion...)
> - things like module constants are back: people.DEFAULT_HEIGHT,
> ofcourse you can modify Meta to allow such, but this is much cleaner in
> modules.
This is pointless. Person.DEFAULT_HEIGHT is really that painful for you?
> - with modules, django can recommend unittesting in "if __name__ ==
> '__main__'"
Erm. What? You could do this already afaics.
>
>>Devoting a module and spreading things give better flexibility.
Erm, no it doesn't. Requiring a module by definition is __less__
flexible. You are removing options.
>>The sole purpose of the module in your example seems to be your
>>particular naming pecadillos.
>
>
>
> No, the sole purpose is to allow a model to be extensible from other places
> [eg Admin related settings defined in single file.] [making GUIAdmin
> possible as a just another app]
Wrong, as shown above.
> we do not have one namespace, we have three: model class, Admin and Meta.
I have no idea what point you are making here. I do *NOT* want to have
to remember both Person *and* people.
> it is a lot of boilerplate if you want a lot of functionality as i
> demonstrated. for simpler cases it is not so:
> #####################################
> from django.db import models
> from django.contrib.admin import Admin
>
> class Person(models.Model):
> first_name = models.CharField(maxlength=30)
> last_name = models.CharField(maxlength=30)
> all = models.Manager(Person)
> Admin(all).register("People")
And here is the boiler plate. Pointless.
> #############################################################
> vs
> #############################################################
> from django.db import models
> from django.contrib.admin import Admin
>
> class Person(models.Model):
> first_name = models.CharField(maxlength=30)
> last_name = models.CharField(maxlength=30)
> class Admin: pass
This is pretty much minimal as far as I can tell.
> So yes, if your application was three model large, you will find the current
> approach simpler, just one file, while I forcing three files. But this is a
> case when things start to become difficult as the project matures. After
> 5-10 you will start thinking of splitting the models across files, group
> them in saner fashion, assuming models are non trivial.
Whereas forcing each model into a seperate file is really fun? We should
allow them in seperate files, if that doesn't work it is a bug. But
forcing them is stupid.
> a) sane defaults with minimal boiler plate. In reality, "most" users are
>
>>never going to touch this multiple managers stuff, and they are not
>>going to have fields called objects.
>
> Agreed, but by saying so we are ruling out module constants, or another
> Admin interface for now, which most users might benefit from.
Wrong.....
> I see managers as purely backend providers. Whatever else you want you can
> do with your own functions.
>
> def tall_people():
> global all
> return all.filter(height > TALL_PERSON_HEIGHT)
Wow, that is really really horrible. Making people think about 'global'?
No thanks.
> b) possibility of customisation in the cases it is needed.
>
>
> But only by modifying the class. What if I want to write a configure admin
> UI? I can not write such an application right now, where as if admin was
> just a set of normal Admin objects, I could write GUI to discover models in
> the app, store a everything in a single file, [they are just a set of
> objects anyways in my proposal].
Rubbish, as said many times before. You could clearly keep whatever you
want in seperate files. You are asking that the ability to specify this
conveniently using inner classes be removed. That is one of the most
useful things about django orm, so...
> So I give this a big fat -1.
>
> I hope you would reconsider. :-)
I'll upgrade it to a -3.
