> I'm not sure whether it's reasonably possible to separate the > DataBinder logic from the Form and Field classes, but please convince > me of the opposite :)
That sounds like a challenge :) Well, i have maybe some arguments, but maybe that you will be the one which convinces me it's not a good idea to separate the two :) First of all, i took a look at the source code and it seems that binding is dependant from form fields definition, i hope that i looked well. In some applications, e.g. with a distributed architecture, the inputs don't necessarily come directly from an html form and can be raw data (like nested arrays) or transfer objects (DTO). In that case, data should be binded directly to business objects by a business layer (e.g. a service layer), without the need of all the form component behaviour (data should be validated directly from the BO) and without the need to not only use the form but in addition declare each form field just to be able to bind data. Plus, having a generic data binder (plugged to Form) brings more flexibility, and it would be far more easy to add behaviour (by overriding the component) to the data binding process. No need to override the entire Form class or the FieldGroup class. It would also be great to be able to use the data binder for specific developments not necessarily linked to Forms or Validation process. I have no specific example in mind right now, but i think it could be a good tool in some designs. br, Benjamin. :) -- 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
