Odp: Re: model fields options
In my opinion Meta class may contain this kind of information, and it would simplify the process of designing models. Especially handling fields which contains a lots of data inserted via arguments. However, I think that the Meta class properties should be an alias or a handy shortcut, not one and only one way of setting those options. -- 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: model fields options
On May 7, 2:21 am, Alex Gaynorwrote: > Sounds like a bad idea to me. unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields. All the other options belond to specific fields. I agree in principle, however I've recently come across a use case where being able to *override* an individual field's options (in my case 'unique') with a simple API from the Model's Meta options would have been nice: http://code.djangoproject.com/ticket/15953 I don't know enough about the ORM to predict if that sort of things could have bad side effects. What do you think? Julien -- 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: model fields options
On Fri, May 6, 2011 at 12:22 PM, legutierrwrote: > Why is help_text part of the field > definition? This is a ui-specific thing--what does it have to do with > the database? All abstractions are leaky, sure, but this seems > inappropriate. The same thing goes for editable, error_messages: > these options are not part of the ORM, they are parts of the forms > subsystem that have somehow ended up in the ORM. Why should the ORM > know anything about forms, or any other part of Django for that > matter? they're UI things, but forms aren't the only UI imaginable. and, they're UI things that belong to the field. not the database field, but the model field. -- Javier -- 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: model fields options
Hi Eduardo, On 05/06/2011 12:22 PM, legutierr wrote: > You're probably right about this, but (while we are on the subject) > aren't there some things that shouldn't be part of the model field > options that currently are? Why is help_text part of the field > definition? This is a ui-specific thing--what does it have to do with > the database? All abstractions are leaky, sure, but this seems > inappropriate. The same thing goes for editable, error_messages: > these options are not part of the ORM, they are parts of the forms > subsystem that have somehow ended up in the ORM. Why should the ORM > know anything about forms, or any other part of Django for that > matter? I think error_messages may actually belong in the ORM now, since model-validation. Totally agreed that editable and help_text don't belong there - I think the fact that they're still there is just a matter of historical inertia, and that nobody's been sufficiently motivated to deal with the backwards-compatibility difficulties to change it. Carl -- 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: model fields options
Not exactly related, but this is how help_text (and other field options) can be moved out from the field definition without patching django: http://djangosnippets.org/snippets/2180/ -- 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: model fields options
> Sounds like a bad idea to me. unique_together doesn't exist on a specific > field precisely because it isn't an option for any specific fields, it's for > a set of fields. All the other options belond to specific fields. > > Alex You're probably right about this, but (while we are on the subject) aren't there some things that shouldn't be part of the model field options that currently are? Why is help_text part of the field definition? This is a ui-specific thing--what does it have to do with the database? All abstractions are leaky, sure, but this seems inappropriate. The same thing goes for editable, error_messages: these options are not part of the ORM, they are parts of the forms subsystem that have somehow ended up in the ORM. Why should the ORM know anything about forms, or any other part of Django for that matter? Eduardo -- 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: model fields options
On Fri, May 6, 2011 at 12:08 PM, Mateusz Harasymczukwrote: > I had an idea. > > To move model fields options, such as: > - blank=BOOL > - null=BOOL > - auto_add=BOOL > - auto_add_now=BOOL > - db_index=BOOL > > and others boolean options to Meta class of this model. > > It would make model fields more readable and human friendly. > However I am not convinced, that it would be a good idea, thou. > > I am just giving an discussion topic. > > it works for unique_together > why not to add: > > unique = ('name', 'login', 'ssn') > db_index = ('name', 'login') > auto_add = ('signup_date', ) > auto_add_now = ('last_mod', ) > null = ('comment', 'first_name') > > ... and so on ... > > What do you think? > > > -- > Matt Harasymczuk > http://www.matt.harasymczuk.pl > > -- > 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. > Sounds like a bad idea to me. unique_together doesn't exist on a specific field precisely because it isn't an option for any specific fields, it's for a set of fields. All the other options belond to specific fields. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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.