Hi, While implementing our collection management system based on Django, we are always excited by the extensibility of the framework. Most recently, we were exposed to the *forms.MultiValueField* and* widgets.MultiWidget*, that seem to offer composition capacities to users of the *form* and *widget* layers. Yet, we did not find any equivalent in the *model* layer, which seemed a bit surprising knowing that those 3 layers can work hand-in-hand very easily
Is there a rationale to prevent implementation of such a models.MultiField class ? It could be a wrapper around the composite pattern in the *model* layer, allowing users to easily define custom models.Field that would leverage existing *models.Field* classes, by assembling them for specific purposes (while maximizing reuse). ---- This question was also raised in Stack Overflow here: http://stackoverflow.com/q/32014748/1027706. Below is a summary of the question's example motivating such feature request: Imagine we want to store partial date in the DB (i.e., a date that is either complete , or just month+year, or just year). We could model it in the models layer using a *models.DateField* + a *models.CharField* (this last field storing whether the date is complete, or month+year, or just year). Now, if we move to the forms layer, let's say we want a custom validation step that when a date is partial, the "unused" part of the DateField must be the value '1'. Because a *ModelForm* automatically maps one *forms.Field* to each *models.Field*, this constraint would require a cross-field validation. On the other hand, if there was a *models.MultiField*, one could define a *PartialDate* class to inherit from said *MultiField*. It would then be seen by other layers as a single *models.Field* (implemented by aggregating two other *models.Field*, but that would be an implementation detail hidden from other layers). In *ModelForm*, this single *models.Field* would map a to a single custom* forms.Field* (probably deriving from *forms.MultiValueField*), and the validation step above would not need to be a cross-field validation anymore (more precisely, this validation could now happen at the *forms.MultiValueField* level, instead of the *Form* level). With this approach, it seems that the *models.PartialDate* and the *forms.PartialDate* could be written once, and reused in as many models and applications as possible, thus respecting Django's DRY philosophy. ---- Could a prototype implementation of such composite model field be of interest ? -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9bded34a-917c-4f02-b9ec-9d9d23fc274a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
