This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.

Fabien Potencier aad2f5868a merged branch mvrhov/form_attributes_option (PR #1032) ... Commits ------- e8326aa Renamed attributes to attr to be consistent with templating. c707467 Added support for additional attributes in Form types that list field as their parent. Discussion ---------- [Form] Added support for additional attributes Added support for additional attributes in Form types that list field as their parent. This is needed particularity for html5 data and data- attributes support, unfortunately $options['data'] is already taken, so adding a general $options['attributes'] is the easiest solution without breaking BC. Now I know that this will be tempting for some to stuck style and class attributes here also, but I'd rather not restrict the keys that are passed in. --------------------------------------------------------------------------- by Seldaek at 2011/05/22 14:51:02 -0700 Maybe it should be called attr for consistency with the template stuff, or the other should be renamed attributes. Other than that, I'm +1, data-* attributes are awesome, and abusers will find ways to abuse things either way. --------------------------------------------------------------------------- by mvrhov at 2011/05/22 21:48:01 -0700 Naming it attr also crossed my mind when I was signing off yesterday. Along with the possibility to go the way xml attributes are handled when node is converted to/from array. So every option with @ prefix would automatically become html attribute. However going the latter path, it'd be harder to implement. --------------------------------------------------------------------------- by fabpot at 2011/06/13 07:43:52 -0700 Can you give an example of a real-world use case? Thanks. --------------------------------------------------------------------------- by Seldaek at 2011/06/13 07:54:51 -0700 You can use `array('attr' => array('data-foo' => 'bar'))`, which will output `data-foo="bar"`, which can be read easily by jQuery for example as `$('el').data('foo')`. It's a standard compliant and elegant way to pass extra data needed by the JS code along with DOM nodes, without polluting everything with script tags and all. --------------------------------------------------------------------------- by fabpot at 2011/06/13 08:01:08 -0700 @Seldaek: I understand that. But why not doing this in the template? --------------------------------------------------------------------------- by Seldaek at 2011/06/13 08:04:10 -0700 Well, I agree it most likely belongs in the template, but it's kind of data stuff that is not directly impacting the display rules of the element, so in some cases having the possibility to set that from the php code might be useful. Anyway I'll let @mvrhov answer maybe he had a more concrete use case. I just think it's nice to leave the door open, but I don't really need it. --------------------------------------------------------------------------- by mvrhov at 2011/06/13 10:27:03 -0700 A bit late to the party. Ok, here is my use-case. I have a pretty large form where part of the data is of tabular form. The number of rows is almost every time a lot larger than the number of columns So I can either output a lot of text inputs filled with data and make already a large form intimidating. Or I can use a grid that supports editing. So I serialize that tabular data as json and put it as a value into one hidden field. Somehow I also have to get the column definitions to that grid. I decided to I serialize it and put it inside data-* attribute. Putting it into another hidden field doesn't make sense as when data is submitted back I don't need the column definitions as only the number of rows changes. --------------------------------------------------------------------------- by fabpot at 2011/06/13 10:44:58 -0700 @mvrhov: ok, but what prevents you from doing this in the template directly? --------------------------------------------------------------------------- by mvrhov at 2011/06/13 11:22:53 -0700 I have to get it into the view somehow. What I'd really not like to do is, iterate through that data in a controller and then pass it as another template variable. --------------------------------------------------------------------------- by fabpot at 2011/06/14 00:10:22 -0700 But the controller is where you prepare the data that you want to send to the view. Without any concrete example, I'm going to close this PR. --------------------------------------------------------------------------- by mvrhov at 2011/06/14 01:21:10 -0700 IMHO this has to go out through form as this is the part of the form also I do have a very slim controllers in this case 10 LOC, where half of them is just setting up an view data.. Nonetheless I went looking again very closely at the AbstractType and I do have buildView function available which I can override and set the column data I need there, and then provide custom view for that, so at least from this part this is an non issue. With this PR all default form attributes can be set from outside and when searching for a good use-case I have found out that @henrikbjorn has implemented this via extensions [1], maybe he has a good use-case for this. [1] - https://github.com/Comways/ComwaysFormExtraBundle/blob/master/Form/Extension/FieldTypeExtension.php --------------------------------------------------------------------------- by henrikbjorn at 2011/06/14 01:48:53 -0700 Convenience is the only use case --------------------------------------------------------------------------- by stof at 2011/06/14 02:08:09 -0700 @fabpot The issue is that passing it from the controller as another template variable makes it really hard when you use the type twice with different values. Passing them from the form would be the easiest way --------------------------------------------------------------------------- by shuogawa at 2011/06/14 19:37:50 -0700 hello. thanks for great form library. I want to support two ways to display additional attributes for form elements. 1) control in template like {{ form_row(form.name, { 'width': '30' }) }} 2) control from php $builder->add('name', 'text', array('attr'=>array('width'=>'30'))); If form elements configure by end user like cms, and form elements dynamically change. The second method is useful. template designer can write {{form_row(form)}} but template designer can not write {{form_row(form.name), { 'width': '30' }}} Thank you --------------------------------------------------------------------------- by fabpot at 2011/06/14 23:01:18 -0700 @shuogawa: That's what I fear. Setting the `width` or any other attribute in PHP is wrong. This belongs to the templates. --------------------------------------------------------------------------- by stloyd at 2011/06/15 00:09:05 -0700 @fabpot Then maybe just restrict allowed tags to `data-*` and don't use `attr` but some other not confusing name ? Just like we do with i.e. `maxlength`. --------------------------------------------------------------------------- by fabpot at 2011/06/15 04:44:25 -0700 I'm going to merge it as a "convenience" tool, but the documentation should clearly state that the only usage should be for `data-*` attributes.		2011-06-15 13:44:37 +02:00
..
Extension	merged branch mvrhov/form_attributes_option (PR #1032)	2011-06-15 13:44:37 +02:00
Fixtures	fixed CS	2011-06-08 19:56:59 +02:00
Guess	fixed CS	2011-06-08 19:56:59 +02:00
Util	fixed CS	2011-06-08 19:56:59 +02:00
AbstractDivLayoutTest.php	[Form] simplified file type class	2011-06-13 18:11:18 +02:00
AbstractExtensionTest.php	fixed CS	2011-06-08 19:56:59 +02:00
AbstractLayoutTest.php	[Form] made it possible to translate the empty value of Choice fields	2011-06-14 08:33:48 +02:00
AbstractTableLayoutTest.php	[Form] fixed xpath	2011-06-10 13:18:09 -07:00
AbstractTypeTest.php	Revert "[Form] changed the way default type names are created to avoid collisions"	2011-06-13 11:47:21 +02:00
FormBuilderTest.php	[Form] fixed test	2011-06-09 12:05:27 +02:00
FormFactoryTest.php	[Form] Added FormTypeInterface::getAllowedOptionValues() to better validate passed options	2011-05-13 18:44:03 +02:00
FormInterface.php	fixed CS	2011-06-08 19:56:59 +02:00
FormTest.php	[Form] fixed isValid() on readOnly forms that have children	2011-06-10 07:11:50 -07:00
PropertyPathTest.php	fixed CS	2011-06-08 19:56:59 +02:00