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
On May 7, 2:21 am, Alex Gaynor wrote:
> 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
On Fri, May 6, 2011 at 12:22 PM, legutierr wrote:
> 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
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
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
> 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
On Fri, May 6, 2011 at 12:08 PM, Mateusz Harasymczuk wrote:
> 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