Well syntactical benefits matters a lot. After all even classes in OOP languages is just a syntactical benefit of the language.
In your example of very crude implementation of meta-class-less form implementation you describe fields in Dict. Well you might have overlooked that it is actually SortedDict, because ordering of fields matters. So I'll need to define fields_order
list as well.
Next big thing is ModelForm. Meta-class approach allows to simply say which Model do I use and which fields in Meta
attribute and it automatically creates and maps fields to model. Without Metaclass approach I would probably have to use something like CreateFieldsFromModel
and MapFieldsToModel
. Or you might do that for me in __init__
method. But wait, __init__
method is already complex enough with lots of arguments like data
, initial
, files
, and more.
class MyForm(Form):
fields = {
'one': ...
...
}
fields_order = [...]
model_fields = ???
Class MyForm2(MyForm):
fields = MyForm.fields + {...}
# ... hey this API sucks! I think I'll go with another framework.
And there are many more things which can be configured in forms and everything is documented.
So for me, because of huge configuration logic, it looks like Form
just asks to be implemented through definition-object and factory-logic. And here comes python with its metaclasses to hide the factory from the user. And it is cool because it makes beginners to think less.
And well yea its syntactical sugar all around and its all about making easy to use API.
And yes it is possible not to use Metaclasses/BoundField or whatever else. In the end it is possible to write all implementation of forms in one function and have all definition in one big dict (or xml?) But will that be easy to use, easy to understand, easy to extend?