Skip to content

Instantly share code, notes, and snippets.

@pborreli
Created April 28, 2010 17:01
Show Gist options
  • Star 5 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save pborreli/382376 to your computer and use it in GitHub Desktop.
Save pborreli/382376 to your computer and use it in GitHub Desktop.
adding ":" to all labels and "*" to all required fields inside symfony 1.3+ forms
<?php
class privateConfiguration extends sfApplicationConfiguration
{
public function configure()
{
$this->dispatcher->connect('form.post_configure', array($this, 'listenToFormPostConfigure'));
}
/**
* Listens to the view.configure_format event.
*
* @param sfEvent An sfEvent instance
* @static
*/
static function listenToFormPostConfigure(sfEvent $event)
{
$form = $event->getSubject();
$widgetSchema = $form->getWidgetSchema();
foreach ($form->getValidatorSchema()->getFields() as $fieldName => $validator)
{
if (isset($widgetSchema[$fieldName]))
{
$label = $widgetSchema[$fieldName]->getLabel() ? $widgetSchema[$fieldName]->getLabel() : sfInflector::humanize($fieldName);
$asterisk = $validator->getOption('required') ? '&nbsp;*' : null;
$widgetSchema[$fieldName]->setLabel($label . $asterisk . '&nbsp;:');
}
}
}
}
@kriswallsmith
Copy link

Looks good, although it doesn't recur into embedded forms (form events were added symfony 1.3, btw).

@pborreli
Copy link
Author

thanks, it doesn't need to occur since it affect all forms, embedded or not

updated description for symfony 1.3 ;)

@n1k0
Copy link

n1k0 commented Apr 28, 2010

Well, an embedded for is not a sfForm derived instance, it's a sfFormFieldSchema (and right, it shouldn't but eh, it's like that and we have to deal with it).

@pborreli
Copy link
Author

$this->embedForm('name', here_is_the_sf_form) :)

@n1k0
Copy link

n1k0 commented Apr 28, 2010

Right, that's because of the new $formClass() instanciation called in this method, neat :-)

@kriswallsmith
Copy link

It just wouldn't work if someone is nesting an sfWidgetFormSchema directly in their form configuration. For example, sfWidgetFormSchemaForEach. But I don't think this is very common.

@pbowyer
Copy link

pbowyer commented Sep 28, 2010

While clean, one disadvantage of this approach is there's no way to add a class attribute to the <label> tag itself. Is there any way to do this with your code?

@pborreli
Copy link
Author

@pbowyer it's easy to set a class on the field adding ie:

$widgetSchema[$fieldName]->setAttributes(array('class' => 'red'));

The main issue is that in admin generator the label is set without any attributes :

[?php echo $form[$name]->renderLabel($label) ?] // in lib\plugins\sfDoctrinePlugin\data\generator\sfDoctrineModule\admin\template\templates\_form_field.php

while renderLabel accepts it :

public function renderLabel($label = null, $attributes = array()) // in \lib\form\sfFormField.class.php

@pbowyer
Copy link

pbowyer commented Sep 28, 2010

@pborreli GitHub broke my message text - I was meaning to add the class to the label, as kris's original code does. I'm actually using this in my own forms rather than the admin generator, so the extra attributes shouldn't be a problem. However, I'm not clear how to set them to be 'usable' from the setLabel() call in your code, vs calling renderLabel directly in a custom formatter (as Kris's example does)? Thanks for your reply!

@jtexier
Copy link

jtexier commented Oct 18, 2010

Really neat method of solving the "required fields problem".
But it seems to not work with widget labels defined on a generator.yml file.
On an admin generated page, it looks like that labels are overriden after the form.post_configure event.
Note that the solution proprosed by Kriss works well in that case.

@pborreli
Copy link
Author

@jtexier indeed this solution is form based, can work while using it inside admin gen but with this limitation, personally i prefer define labels inside form and when it need to be overridden i do it inside generator.yml. so it's a feature ;)

@jtexier
Copy link

jtexier commented Oct 18, 2010

I agree with you on defining labels inside a class rather than on generator.yml file.
Unfortunatly, generator.yml is useful to globally define labels for list table columns, filter and form widgets.

Anyway, labels should be handled by only one class (the model one) and should be overriden by related form or filter classes if necessary...

@luads
Copy link

luads commented Jan 13, 2011

I've got duplicated asterisks on merged forms, so I've done this:

   if (substr($label, -1, 1) != '*') {
      $asterisk = $validator->getOption('required') ? '*' : null;
      $widgetSchema[$fieldName]->setLabel($label . $asterisk);
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment