-
-
Save pborreli/382376 to your computer and use it in GitHub Desktop.
<?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') ? ' *' : null; | |
$widgetSchema[$fieldName]->setLabel($label . $asterisk . ' :'); | |
} | |
} | |
} | |
} |
thanks, it doesn't need to occur since it affect all forms, embedded or not
updated description for symfony 1.3 ;)
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).
$this->embedForm('name', here_is_the_sf_form) :)
Right, that's because of the new $formClass() instanciation called in this method, neat :-)
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.
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?
@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
@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!
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.
@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 ;)
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...
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);
}
Looks good, although it doesn't recur into embedded forms (form events were added symfony 1.3, btw).