Am 15.03.2006 um 07:39 schrieb Russell Keith-Magee: > 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.
I definitely agree that the model layer should do validation, as long as that doesn't mean it's the *only* layer that does validation (that's not how I understood the proposal, but some some of the comments seemed to imply that). I may have forms that don't map 1:1 to models; for those, parts of the validation must be done by the formwrapper/manipulator, and other parts by the model classes. > 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. That phrase is about network protocol implementations, I don't think it applies equally to programming interfaces ;-) There's a thin line here between convenient auto-conversion (e.g. strings to numbers) and overloading the model class with logic that simply doesn't belong there. In your web layer code, you have something akin to a manipulator sitting between your model classes and the view. The manipulator would be responsible for unmarshalling POST parameters into a data structure that can be handled by the model, including parsing stuff like dates and exploding "dotted" parameters into nested dicts or whatever. > 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). Example: the string representation of a date in may depend on the locale of the remote user, which the model knows nothing about. The conversion from string to datetime will need to happen in a layer that is aware of the HTTP request context. (This is a somewhat contrived example due to the abysmal state of international datetime formatting/parsing in the Python standard library, but I'm sure there are other examples). Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
