On 20 Feb 2009, at 18:14, Jonathan Wage wrote:
> I would for sure use the form framework and design your own form > classes to handle the specific scenario needed. Using the forms > generated from your models won't be of much assistance I don't think. In this instance, that's not really an option - the requirement is that we need to build dynamic forms without needing a developer. Every new questionnaire would need (at the very least) a new form class, if not a new model... once we'd added 50 or so, autoloading all those classes would become a problem (not to mention deciding on a sensible naming convention, routing, etc...) > On Fri, Feb 20, 2009 at 6:53 AM, Gandalf <[email protected]> wrote: > > I Inherit from sform and pass an object from the class that the form > will represent, in the configure method, I add widgets and validators > while iterating in the object I passed. Sorry, I'm lost. In my implementation the form won't represent a concrete object. It will represent an abstract 'field container' object (although, in theory, this could be any type of data object - its just a container), which will contain many field objects. Does it help explaining it like that? So, the abstract class could be say... "car" or "invoice" or "asset". Anything. Your code has hardcoded widgets and options in it - that's not what I want. > On 2/20/09, David Herrmann <[email protected]> wrote: > > > 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. As far as I understand, a form relates directly to a concrete object. If this is the case, it's going to be difficult - if not impossible - to use the new forms framework. I'm considering COMPAT_10 because it may work - the old forms system is actually a lot more flexible :) > > 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) By this, I assume you mean different validated field types? eg textareaField, inputField, selectField, radioField etc? > > *) 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. Hmm.... possibly. ideally though, you only want to recreate the form whenever it's changed, not on every request. > > 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. I think once the solution has been identified it will not take much work to get a proof of concept working. It could prove tricky to add some advanced cases and validators though. > > 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. I have no doubt that the new forms framework is very powerful, but I think in this instance it could be difficult to bend it to conform to do something it was never designed to. The old forms system is a lot less rigid - so I've got a lot more confidence that using the old system would work. Infact, I can see Symfony 1.0 plugins that look worth investigating - spyFormBuilderInterfacePlugin and sfDynamicsFormBuilder > > 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. I'll make it a plugin... I've just created sfDynamicFormsPlugin. I'll base it on DbFinder, so it works with both Doctrine and Propel If anybody that wants to join it, please do - i'd like to see some demo's of the different concepts that have been suggested :) I think this will be one of those plugins that nobody knew they wanted until it existed... it opens up a few possibilities, you no longer need 1 module per model for CRUD, in some apps, you may not even need ANY models anymore... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
