Hello Lee, read my reply on the other thread.
On 2/21/09, Lee Bolding <[email protected]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
