Hi everybody.
I deeply feel that form field guessing should rely on validation
constraints, not ORM mapping.
These are some reasons:
*1) ORM mapping logic/implementation may differ from validation constraints.
*
Lets say we have a CREDIT CARD property for some entity. So we decide it to
be a String type for the database (ORM)
because it is 16 digits long and a mysql Integer type doesn't allow that
many digits. Also, on the app layer a String is easier to work with.
For example: We could use a simple string formatter function to add a (-)
separator each 4 digits (this goes in the View layer).
Lets say validation contraints will requiere a user to submit an Integer (16
digits long). Lets says that the use case require us as
developers to implement one textfield to input only digits.
To my point of view, this scenario is ok: I require you to submit just
digits/number in the form field, but in my application
I will treat that data as a string, and persist those valid numbers as a
string in the DB.
The problems comes here:
*2) Relying on both ORM mapping could lead in breaking validation service.*
I realize that form field guessing relies on ORM mapping.
If I set a constraint that requires an Integer type for credit_card property
in the validation file (validation.yml), but I have a String type for it
in the ORM mapping (**.dcm.yml) the validation service will throw a "this
value should be of type Integer",
when submitting a valid integer number.
This is because the guessed field renders a <input type=*'text'* ../> based
on ORM mapping (it ignores the integer validation constraint data type).
And <input type=*'text'* ../> will always return a string, even if a number
is submitted
(123 will become '123', the first is a Integer type, the last one is a
String type), that is why the form is not valid.
The validation constraint say that data should be integer and '123' is not
an integer what is correct (validation service is working as expected)
Validation services relies on validation.yml, but form field guessing does
not, instead it is based on ORM data type mapping.
If I set Integer type instead of String type in my ORM mapping the guessed
field renders a <input type='*number'* .../>.
This one will return a number if I submit a number (123 will be 123 when
handling the form object).
The source for guessing form field type is ORM data type mapping. But
Validation service is based on validation.yml.
Knowing that both validations constraints and forms works tightly, they
should have the same source, this should be validation.yml.
What I suggest is to rely only on validation constraints for form field
guessing, and if there are no validations contraints for an entity then fall
back on ORM data type mapping.
I'm pretty sure that Field Guessing is using ORM mapping for data
normalization/consistency between the form object and the entity object/(db
table) when
binding ($form->bindRequest($request));
But the problem is there. That is why I think forms should be ORM data type
agnostic.
*I. Setting up manually an Integer Field.*
Assuming that orm data type mapping for credit card is String and validation
constraints expect an Integer, doing something like:
$builder->add('creditcard', 'integer')
on a form bulider will solve the problem, but the point is that Field
guessing should be based on validation data type constraints if there is
one. (DRY).
*II. A problem with this approach.?*
*
*
Lets say we rely only on Validation.yml for field guessing.
What if in ORM mapping I set Integer for credit_card property, but in
validation contraints I require it to be String. If someone submits "123abc"
in
the form, the validation service will say it is valid, but when persisting
the object there will be a problem because the DB server will reject it as
integer is expected.
Also, someone could say that this approach breaks the DRY concept, because
you have to specify data type twice for a property: in the ORM
mapping (for DB purpose) and the validation contraints (for form field
guessing purpose) to get a working form field guessing.
But this is why I suggest that if there is no validation constraint for data
type, then fall back to ORM mapping data type.
I know that Forms and Entities work tightly, but I must remark that a Form
should be just a data collector.
What if the Form Framework grows so big that in a few month it is so
decoupled that you can integrate it in differents projects
(simple projects, or maybe codeIgniter, cakePHP), the first things I would
think about its components are:
The Form Framework + Validation rules/constraints (validation.yml).
It would be very simple: you just register the FF namespace/service , write
some POPOs, and one validation.yml for those entities,
and that's it, you have a fully functional decoupled FF. The FF would still
bind its data to a POPO, but the
devolper would has the last word and the only responsable of normalized data
type.
Looking at this wonderful and futuristic scenario, where only validation.yml
is needed for Form field type guessing,
my suggestion (IMHO) is not that bad as it sounds. Is it?
--------------------
What do you have to say??? I would be very very glad to hear opinions,
corrections, updates, and critics to my suggestion.
Thanks for reading this far.
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
