> In essence, what I'm creating is a form designer similar to > ExpressionEngine custom fields here : > http://expressionengine.com/docs/cp/admin/weblog_administration/custom_fields_edit.html, > the difference being that I'm going to be adding a few extra fields > for validation.
I will need something very similar for customizable forms in a few months time. I'm not sure yet how to realize it but I've already spent some time thinking about it. > So, my question is : how can I get this method to work with the > Symfony forms and validators? Ideally, I don't want any manual > intervention once this is set up. > > With the new forms, it looks like it could be quite difficult, > because a questionnaire doesn't relate directly to a model (and even > if it did, autoloading all of those objects would kill any server). > However, I'm wondering if this would be far easier by enabling > COMPAT_10 and dynamically creating a validator.yml each time a new > questionnaire is created? I think falling back to COMPAT_10 is one of the things I wouldn't even consider. If you can create validator.yml files on the fly, you can also create forms on the fly. The road to the solution must be something like this: *) setup a list of possible objects and possible options for those objects (yaml comes to mind here) *) create a DB schema to store objects and their settings in it (the settings could even be serialized PHP, depending on how abstract you need it) *) write a Form class based on sfForm that creates all the form elements and validators based on the possibilities from the yml file and the options from the database on the fly. I know that this sounds like a lot of work, but I think that most of it is actually quite simple - and once you've got it up and running there is maximum flexibility and options for further objects at hardly any cost. Start with the absolute minimum you need (e.g. text boxes and selects) and add further object definitions as necessary. The old validator.yml is a good base to build the option range upon, but that's where its use should end. The current form framework is much too powerful to ignore it. This whole thing of course screams for being developed as a generic "dynamic form plugin", even if you don't want to (or can't) make it public - when it's a plugin, you can test it and make sure there are no dependecies and maximum reusage options in the future. David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
