How are you questionnaires setup? If they're configured in the  
database, you should be able to present and validate them using you  
Doctrine forms and the something similar to what Gandalf has pasted  
below... Or am I misunderstanding?

--

Kris Wallsmith | Community Manager
kris.wallsm...@symfony-project.com
Portland, Oregon USA

http://twitter.com/kriswallsmith

On Feb 20, 2009, at 10:14 AM, 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.
>
> - Jon
>
> On Fri, Feb 20, 2009 at 6:53 AM, Gandalf <ganda...@gmail.com> wrote:
>
> Hello,
>
> I do that all the time:
>
> 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.
>
> I even write a brand new renderer, very much like the list one, that
> allows me to render mi forms and use wuufo css/templates.
>
> Works like a charm.
>
> Best,
>
> Pablo
>
> Here is a taste:
>
> [php]
> <?php
> class ProcurementFormStep3 extends sfForm
> {
>  protected $procurement;
>
>  protected static $choices = array ('Yes' => "Yes",
>                                     'No' => 'No' ,
>                                     'I\'m not sure' => 'I\'m not  
> sure');
>
>  function __construct ($procurement) {
>    $this -> procurement = $procurement;
>    parent :: __construct ();
>  }
>  public function configure()
>  {
>    $widgets = array('user_code' => new sfWidgetFormInputHidden ());
>    $validators = array('user_code' => new sfValidatorDoctrineChoice
> (array('model' => 'Procurement', 'column' => 'user_code'),
> array('required' => 'Required')));
>    $post_validators = array();
>    $provisions = $this -> procurement -> getAllProvisions ();
>    foreach ($provisions as $provision) {
>      $widgets [sfConfig::get
> ("app_procurement_wizard_select_prefix").$provision -> id] =  new
> sfWidgetFormChoice (
>                            array ('choices' => self::$choices ,
>                                   'expanded' => true,
>                                   'renderer_options' => array
> ('formatter' => 'RawChoicesFormatter::formatter')));
>      $widgets [sfConfig::get
> ("app_procurement_wizard_explanation_prefix").$provision -> id] = new
> sfWidgetFormTextarea() ;
>      $this->setDefault(sfConfig::get
> ("app_procurement_wizard_select_prefix").$provision -> id, 'Yes');
>      $validators [sfConfig::get
> ("app_procurement_wizard_select_prefix").$provision -> id] = new
> sfValidatorChoice(array('choices' => array_keys(self::$choices)));
>
>      $post_validators [] = new gStep3Validator (
>                                 sfConfig::get
> ("app_procurement_wizard_select_prefix").$provision -> id,
>                                 sfConfig::get
> ("app_procurement_wizard_explanation_prefix").$provision -> id,
>                                 array(),
>                                 array ('invalid' => 'Explanation is
> required') );
>      $validators [sfConfig::get
> ("app_procurement_wizard_explanation_prefix").$provision -> id] = new
> sfValidatorString(array('required' => false));
>    }
>    $this->setWidgets($widgets);
>    $this->setValidators($validators);
>    $this -> validatorSchema->setPostValidator (new sfValidatorAnd
> ($post_validators));
>    $this->widgetSchema->setFormFormatterName('raw');
>    $this->widgetSchema->setNameFormat('step3[%s]');
>  }
>  public function getSelectWidgetByCode ($aCode){
>    return $this [sfConfig::get
> ("app_procurement_wizard_select_prefix").$aCode];
>  }
>  public function getExplanationWidgetByCode ($aCode){
>    return $this [sfConfig::get
> ("app_procurement_wizard_explanation_prefix").$aCode];
>  }
>
> }
>
> On 2/20/09, David Herrmann <d...@okto.tv> wrote:
> >
> >> 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
> >
> > >
> >
>
>
>
>
>
> -- 
> Jonathan H. Wage
> Open Source Software Developer & Evangelist
> http://www.jwage.com
> http://www.doctrine-project.org
> http://www.symfony-project.org
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to 
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/symfony-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to