On 3/13/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
I'm late to this discussion, but I have to say I'm +1 as implemented.
My only suggestion relates to validation conditions that aren't bound to a single field - e.g., field1 + field 2 > 10, exactly one of these three date fields must be in the future. How about adding a model-wide validation step (using a list of model wide validators specified on the Meta class)? I imagine the model wide validators would be checked after all the individual field validators have been applied. Invalid model-level validators would return in the validation dictionary under the key 'None', with a list of validation error strings. Comments?
Addressing the arguments against::
1) Validation shouldn't be in the model
If validation isn't in the model, then the model is little more than a light data container; if all you have is a light data container, then the onus is on the user to ensure that validation conditions are checked and rechecked whenever they are used (which smacks of code duplication to me). Putting validation right in the model means that it is never missed.
2) Instantiation shouldn't be from string
Adding string instantiation just seems straight up powerful. Push data in in any meaningful format, and it will get converted (if possible) to the internally preferred representation. Some have called this 'magic' - to me, it's just being liberal in what you accept, but conservative in what you produce.
There have been some interesting proposals for separating 'instantation from data' from 'instantiation from string'; While I understand the sentiment, I'm just not sure they're worth the effort. The only use case I can see here is if the way a string is interpreted will vary depending on the data source, but I don't see this as very likely (or even advisble).
Russ Magee %-)
Thoughts, criticisms? The only part I'm sketchy on is the side effect
of converting the values to their Python data types. The
cleanliness/consistency is quite nice, but it's slightly not something
a developer might expect. However, we can solve the latter through
clear documentation.
I'm late to this discussion, but I have to say I'm +1 as implemented.
My only suggestion relates to validation conditions that aren't bound to a single field - e.g., field1 + field 2 > 10, exactly one of these three date fields must be in the future. How about adding a model-wide validation step (using a list of model wide validators specified on the Meta class)? I imagine the model wide validators would be checked after all the individual field validators have been applied. Invalid model-level validators would return in the validation dictionary under the key 'None', with a list of validation error strings. Comments?
Addressing the arguments against::
1) Validation shouldn't be in the model
If validation isn't in the model, then the model is little more than a light data container; if all you have is a light data container, then the onus is on the user to ensure that validation conditions are checked and rechecked whenever they are used (which smacks of code duplication to me). Putting validation right in the model means that it is never missed.
2) Instantiation shouldn't be from string
Adding string instantiation just seems straight up powerful. Push data in in any meaningful format, and it will get converted (if possible) to the internally preferred representation. Some have called this 'magic' - to me, it's just being liberal in what you accept, but conservative in what you produce.
There have been some interesting proposals for separating 'instantation from data' from 'instantiation from string'; While I understand the sentiment, I'm just not sure they're worth the effort. The only use case I can see here is if the way a string is interpreted will vary depending on the data source, but I don't see this as very likely (or even advisble).
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
