This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » support » General discussion » is sfForm better than form helpers?, please vote!
is sfForm better than form helpers?, please vote! [message #62821] Fri, 10 October 2008 18:12 Go to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member

is sfForm better than form helpers?[ 22 vote(s) ]
1.Yes, new sfForm rocks! (symfony 1.1) 15 / 68%
2.No, old helper system better! (symfony 1.0) 7 / 32%

curious to know if everyone is happy with new sfForm system or who is not.

Please vote & comment why you like/don't like etc.!

Re: is sfForm better than form helpers?, please vote! [message #62823 is a reply to message #62821 ] Fri, 10 October 2008 18:14 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
I personally vote "no", I will explain my "no" later here, so I expect same from everyone.

Thanks!
Re: is sfForm better than form helpers?, please vote! [message #62824 is a reply to message #62823 ] Fri, 10 October 2008 18:23 Go to previous messageGo to next message
weaverryan  is currently offline weaverryan
Messages: 781
Registered: November 2007
Location: Nashville, TN
Faithful Member

Vote for yes (the voting is broken on the forum I believe).

Listen, forms are used to interact and update with our models. The new form system is a marriage between our models and our forms, as it should be. The system is fully Object-Oriented and does tons of stuff automatically for you (e.g., see file upload in sf 1.2). Furthermore, the validation framework is the right way to perform validation from a security standpoint with extra fields being automatically detected.


Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
Re: is sfForm better than form helpers?, please vote! [message #62826 is a reply to message #62824 ] Fri, 10 October 2008 18:43 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
broken? worked to me. 220853

I understand what sfForm is, there's no need to explain it, I just want to hear what exactly people don't like/like in sfForm/from helpers.

Thank you!
Re: is sfForm better than form helpers?, please vote! [message #62829 is a reply to message #62826 ] Fri, 10 October 2008 18:56 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
I'll opt for yes, although I've not converted to 1.1 yet. Incidentally I think weaverryan's explanation is quite helpful even if you believe you know how sfForm works and how to use it - I have seen one or two negative reactions from people who have clearly struggled with the extra object orientation.


Remember Palestine
Re: is sfForm better than form helpers?, please vote! [message #62831 is a reply to message #62821 ] Fri, 10 October 2008 19:09 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
guys, please vote if you used sfForm, there's no need to vote "yes/no" if you didn't.
Re: is sfForm better than form helpers?, please vote! [message #62840 is a reply to message #62831 ] Fri, 10 October 2008 19:58 Go to previous messageGo to next message
trontank  is currently offline trontank
Messages: 179
Registered: July 2008
Location: Germany
Senior Member
Yes. I have to say that the new form system has a quite steep learning curve and that I ran into several problems when I tried it for the first time, but so far I like it. Here's hoping for a complete documentation of the new form system, new custom widgets and tutorials.
Re: is sfForm better than form helpers?, please vote! [message #62862 is a reply to message #62821 ] Sat, 11 October 2008 09:31 Go to previous messageGo to next message
cokker  is currently offline cokker
Messages: 582
Registered: January 2007
Location: Germany
Faithful Member
I will not vote.

I have a mixed opinion on sfForm. All I have read about it, it is great for standard forms. But for complex forms it is no help.

greets
Sven
Re: is sfForm better than form helpers?, please vote! [message #62863 is a reply to message #62821 ] Sat, 11 October 2008 09:50 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
Ok, I see a lot of OO fanatics heh..

I think the form creation should be as easy as possible, that is lack of sfForm, sfForm is for programmers, really.
Re: is sfForm better than form helpers?, please vote! [message #62866 is a reply to message #62863 ] Sat, 11 October 2008 10:12 Go to previous messageGo to next message
michael.piecko  is currently offline michael.piecko
Messages: 624
Registered: June 2006
Location: Germany
Faithful Member
letbeserious wrote on Sat, 11 October 2008 09:50

... sfForm is for programmers ...

And i thought we ARE "programmers" ... Damn it! Cool

Michael
Re: is sfForm better than form helpers?, please vote! [message #62867 is a reply to message #62866 ] Sat, 11 October 2008 10:19 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
glad you've figured it out, wasn't sure? hehe..
Re: is sfForm better than form helpers?, please vote! [message #62869 is a reply to message #62831 ] Sat, 11 October 2008 13:20 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
letbeserious wrote on Fri, 10 October 2008 18:09

guys, please vote if you used sfForm, there's no need to vote "yes/no" if you didn't.

Well, I modified the My First Project tutorial to work with the new form system, so I have used it. Just not on very complex stuff.

@weaverryan: voting works here, AFAICT.


Remember Palestine
Re: is sfForm better than form helpers?, please vote! [message #62870 is a reply to message #62866 ] Sat, 11 October 2008 13:21 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
michael.piecko wrote on Sat, 11 October 2008 09:12

And i thought we ARE "programmers" ... Damn it! Cool

Giggle Very Happy


Remember Palestine
Re: is sfForm better than form helpers?, please vote! [message #62873 is a reply to message #62821 ] Sat, 11 October 2008 13:29 Go to previous messageGo to next message
michael.piecko  is currently offline michael.piecko
Messages: 624
Registered: June 2006
Location: Germany
Faithful Member
@weaverryan:
@halfer:

Voting does work when you came directly from the forum page, for example http://www.symfony-project.org/forum/ to this topic.

I noticed that it doesn't work, when you came from the community page http://www.symfony-project.org/community using a link there.

Michael
Re: is sfForm better than form helpers?, please vote! [message #62884 is a reply to message #62873 ] Sat, 11 October 2008 18:48 Go to previous messageGo to next message
weaverryan  is currently offline weaverryan
Messages: 781
Registered: November 2007
Location: Nashville, TN
Faithful Member

huh, that explains it - I remember a different post like a year ago when I couldn't vote either - a legitimate, albeit not too important, bug in the forum

@letbeserious - OO fanatics? Do you prefer flat functions over classes that you can override?


Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
Re: is sfForm better than form helpers?, please vote! [message #62888 is a reply to message #62863 ] Sat, 11 October 2008 20:17 Go to previous messageGo to next message
lkrubner  is currently offline lkrubner
Messages: 297
Registered: July 2008
Location: Virginia, USA
Faithful Member
Ok, I see a lot of OO fanatics heh..

I think the form creation should be as easy as possible, that is lack of sfForm, sfForm is for programmers, really.


I'm not sure I understand the complaint. Why use Symfony if you don't want an OO environment? There are other PHP frameworks that allow for a more procedural style.

Is your complaint that the scaffolding should empower non-programmers? I'd agree with that. I worked on such a project for most of 2006, for a different framework. I'd love to see something like that for Symfony. There are similar projects being evolved for Ruby on Rails. But you should be more clear about why you are complaining about OO.



Symfony Experts offers answers: http://www.symfonyexperts.com/
Re: is sfForm better than form helpers?, please vote! [message #62896 is a reply to message #62821 ] Sat, 11 October 2008 22:33 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
wow!, there are no complaints regarding OO from me nor regarding symfony at all, just some people here say that sfForm OO etc. and that's why it's better!

I actually expected to see here how sfForm made form creation easier for you!
Re: is sfForm better than form helpers?, please vote! [message #63278 is a reply to message #62821 ] Thu, 16 October 2008 18:10 Go to previous messageGo to next message
GaryFx
Messages: 377
Registered: May 2008
Location: Masschusetts
Faithful Member
I don't think the problem is that the new sfForm system is too O-O, although it may be too Java-like.

I believe the problem is that the new sfForm system discards what had been one of symfony's best features, namely its integrated, hierarchical templating system. The system is still there, but it's simply unusable for form elements.

It also broke the MVC separation of concerns. Yes, I've read Fabien's blog posting on the subject, but I find the examples too simplistic to be persuasive. The real issue is that the article ignores the way the WidgetFormSchema is created. The article shows it as a black box representing the view, but in fact the forms book shows the schema being configured directly in the form, breaking that separation. Another way of looking at this is that the WidgetFormSchema system exposes an interface that is too low level.

For example, chapter one of the forms book shows
'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects))

inside the configure method of the form definition. Suppose the visual designer decides this should really be a radio button? That means the designer has to go into the form definition (ostensibly part of the Controller, not the View), and change the call.
Re: is sfForm better than form helpers?, please vote! [message #63280 is a reply to message #62821 ] Thu, 16 October 2008 18:20 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
that is it, with sfForm simplicity is lost.

by combining/nesting validators makes code really hard to read


real example
$this->setValidators(array(
    'domain_name'           => new sfValidatorString(array('required'  => true), array()),
    'domain_url'            => new sfValidatorAnd(array(
    new sfValidatorUrl(array('required'  => true), array('invalid' => '*******************.')),
    new sfValidatorCallback(array('callback' => array($this, 'checkDomainUrl')), array('invalid' => ' ***********************.'))
    ),
    array('required' => true),
    array('required' => '********************.')
    ),
    'domain_status'    => new sfValidatorBoolean(array('required'  => true), array('required'  => 'Domain status is required.')),
    ));

    $this->validatorSchema->setOption('allow_extra_fields', true);


isn't it harder to read comparing it to helpers/yaml?
Re: is sfForm better than form helpers?, please vote! [message #63282 is a reply to message #63280 ] Thu, 16 October 2008 18:38 Go to previous messageGo to next message
weaverryan  is currently offline weaverryan
Messages: 781
Registered: November 2007
Location: Nashville, TN
Faithful Member

You wouldn't write your proposed YAML that sloppy would you? While I think there's probably some truth to what you said, your code should at least be formatted properly if you're going to contrast its readability with that of YAML:

$this->setValidators(array(
  'domain_name'  => new sfValidatorString(
    array('required'  => true)
  ),
  'domain_url'   => new sfValidatorAnd(
    array(
      new sfValidatorUrl(
        array('required'  => true),
        array('invalid' => '*******************.')
      ),
      new sfValidatorCallback(
        array('callback' => array($this, 'checkDomainUrl')),
        array('invalid' => ' ***********************.')
      ),
    ),
    array('required' => true),
    array('required' => '********************.')
  ),
  'domain_status' => new sfValidatorBoolean(
    array('required'  => true),
    array('required'  => 'Domain status is required.')
  ),
));

$this->validatorSchema->setOption('allow_extra_fields', true);


The above doesn't look nearly as bad, I find it quite readable. Now, it's not as clear as YAML, but YAML has its own drawbacks. Namely, I'm comfortable with PHP syntax, but still (to this day) not comfortable with some of the more advanced syntax of YAML. If there were ever a YAML of the form framework, I'd just want it to generate the PHP for me so that I can do my more advanced features after getting off to that a headstart via YAML.

Also, consider that the above is pretty much a "worst case scenario". The above shows all of the validators being set in one call, along with a ValidatorAnd and a ValidatorCallback (2 of the most cumbersome validators). It really wouldn't normally get more complicated than the above (apart from nesting AND or OR validators down many levels).

Also, not that I know what your project is (I do this when necessary), but your allowing of extra fields on the last line undoes one of the most important feature of the new form framework. Namely, the fact that the forms are tied directly to the model means that, normally, the form framework prevents users from injecting extra fields that you didn't intend.


Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
Re: is sfForm better than form helpers?, please vote! [message #63284 is a reply to message #63282 ] Thu, 16 October 2008 19:02 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
that code is formatted in my editor (eclipse)
though I find it harder to read than it would be helpers in templates and validation rules in yaml.


sfForm reminds me HTML_QuickForm heh.
Re: is sfForm better than form helpers?, please vote! [message #63300 is a reply to message #62821 ] Thu, 16 October 2008 22:50 Go to previous messageGo to next message
naholyr  is currently offline naholyr
Messages: 223
Registered: June 2007
Faithful Member
The thing I hate in sfForm is its heaviness for the common tasks.

I can think about many situations, but I never find a case where sfForm can be better than old system (helpers + validation) :
  • The easy <?php echo $form ?> ? No really, in real life there is no client who will accept the direct output. There is always a need for changes.
  • The binding with model ? Well... why not, but honestly do we really need such a feature when we have admin generators ? 90% of the backend was handled by admin generators (sfForm does not bring any benefit here), and 90% of the frontend forms are not bound to any model (contact form, subscribtion forms, etc...). This binding is useful only for the ultra-known cases (blogging, posting, editing profile). OK, but what about the other cases ?
  • We lose validate.yml which was so neat and readable. Well I appreciate the fact that the validation is now attached to the form and not the action, but we didn't have to lose our nice YAML Sad
  • We lose action's validate method, that is sad because keeping the form validation + action validation could have brought two layers, and then more flexibility ('cause yes, sometimes validation does not only depend on the form, but also on *where* the form is used, namely the action).



In my opinion, this is heavier, breaks the MVC philosophy when we want to easily change output, and brings very small benefits, in very few particular cases (make model forms, but not in a generic backend context).


I love all changes in 1.1 (particularly the sfApplicationConfiguration thing, which allows many tricks), but this *thing*... I really cannot understand why it has been done this way Sad

[Updated on: Thu, 16 October 2008 22:56]

Re: is sfForm better than form helpers?, please vote! [message #63307 is a reply to message #63300 ] Fri, 17 October 2008 02:00 Go to previous messageGo to next message
weaverryan  is currently offline weaverryan
Messages: 781
Registered: November 2007
Location: Nashville, TN
Faithful Member

Quote:

90% of the frontend forms are not bound to any model


Quote:

The thing I hate in sfForm is its heaviness for the common tasks


I agree with both of those comments very strongly. My biggest complaint is that, while there are many great things done automatically for you, the simple things have gotten harder. My hope is that there will ultimately be a much easier way to do the simple things and that it's just a matter of the framework evolving and documentation improving.


Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
Re: is sfForm better than form helpers?, please vote! [message #63340 is a reply to message #63307 ] Fri, 17 October 2008 12:29 Go to previous messageGo to next message
trontank  is currently offline trontank
Messages: 179
Registered: July 2008
Location: Germany
Senior Member
I wish there were shortcut methods for certain things, ie setValidator instead of:

$validatorSchema = $this->getValidatorSchema();
$validatorSchema['myfield'] = new sfValidatorSomething();


And setWidget instead of:

$widgetSchema = $this->getWidgetSchema();
$widgetSchema['myfield'] = new sfWidgetFormInput();
Re: is sfForm better than form helpers?, please vote! [message #63342 is a reply to message #62821 ] Fri, 17 October 2008 12:41 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
I totally agree with trontank, these two methods would allow us to format code better

sfForm::setWidget('field', new sfWidgetFormInput() );
sfForm::setValidator('field', sfValidatorString() );


do we submit a ticket?
Re: is sfForm better than form helpers?, please vote! [message #63344 is a reply to message #62821 ] Fri, 17 October 2008 12:51 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
the worst thing I hate in sfForm is radiobuttons and such

I always have to do like this

'status' => new sfWidgetFormSelectRadio(array('choices' => array('1' => 'Active', '0' => 'Pause'), 'formatter'=> array($this, 'selectRadioFormatter'))),



and fomatter method

public static function selectRadioFormatter($widget, $inputs)
	{
		$rows = array();
		foreach ($inputs as $input)
		{
			$rows['input'][] = $input['input'];
			$rows['label'][] = $input['label'];
		}

		return $rows;
	}



and in template I do like


<?php
 $status_buttons = $form['status']->render() 

echo $ad_type_buttons['input'][0];
echo $ad_type_buttons['label'][0];

echo $ad_type_buttons['input'][1];
echo $ad_type_buttons['label'][1];

?>



looks so ugly, I had to run render() method in template (that is part of 'controller' I think, not a 'view'),

can anyone suggest better way?
Re: is sfForm better than form helpers?, please vote! [message #63371 is a reply to message #62821 ] Fri, 17 October 2008 17:58 Go to previous messageGo to next message
GaryFx
Messages: 377
Registered: May 2008
Location: Masschusetts
Faithful Member
For what it's worth,I just caught up with this blog post on the new sfWidgetFormChoice method in 1.2. This additional abstraction is a step in the right direction, but doesn't really solve the problem. The decision between radio buttons and drop-down list is still being made in the controller. But at least it's going in the right direction, towards more abstract, less view-specific widgets.
Re: is sfForm better than form helpers?, please vote! [message #63375 is a reply to message #62821 ] Fri, 17 October 2008 18:10 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
Out of interest, is anyone using 1.1 here and deliberately using the 1.0 compatibility mode because they don't get on with sfForm? I am due to convert a big project and would be interested in other peoples' experience of this.


Remember Palestine
Re: is sfForm better than form helpers?, please vote! [message #63415 is a reply to message #63375 ] Sat, 18 October 2008 14:41 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
halfer wrote on Fri, 17 October 2008 18:10

Out of interest, is anyone using 1.1 here and deliberately using the 1.0 compatibility mode because they don't get on with sfForm? I am due to convert a big project and would be interested in other peoples' experience of this.


I do not, otherwise there's no reason to upgrade at all.
Re: is sfForm better than form helpers?, please vote! [message #63456 is a reply to message #63375 ] Sun, 19 October 2008 18:50 Go to previous messageGo to next message
GaryFx
Messages: 377
Registered: May 2008
Location: Masschusetts
Faithful Member
I'm using 1.1 in compatibility mode on one project, not strictly because I don't get along, but because there are too many dependencies that would need to change, and it's not worth the effort.

Part of the issue is that there's nothing bad per se about the compatibility mode features. I'm not sure that removing them is justified. I can imagine that there may be potential security issues, but haven't looked closely enough to see if that's a real problem, let alone one that justifies the removal.
Re: is sfForm better than form helpers?, please vote! [message #63459 is a reply to message #63282 ] Sun, 19 October 2008 19:19 Go to previous messageGo to next message
GaryFx
Messages: 377
Registered: May 2008
Location: Masschusetts
Faithful Member
weaverryan wrote on Thu, 16 October 2008 12:38

You wouldn't write your proposed YAML that sloppy would you? While I think there's probably some truth to what you said, your code should at least be formatted properly
...

The above doesn't look nearly as bad, I find it quite readable.


Actually, I find your worse. The reason is that the required => true and the invalid => ... entries are essentially at the noise level unless you're specifically looking for them. In other words, if you're trying to grok the code structure, they get in the way. Putting them inline vertically obscures the outline, whereas the original makes it easy to pull out the items being affected (ignoring an indentation error in the original). I don't know what percentage of people rely heavily on vertical scanning of the leading test of lines, but I know it's a common enough behavior to be worth accommodating by keeping noise away from the left edge. The outline I'd like to see is:
'domain_name'      => new sfValidatorString( ...),
'domain_url'       => new sfValidatorAnd( ...),
'domain_status'    => new sfValidatorBoolean( ... ),

Which makes it easy to pick out the fields being validated. Either one could be improved with some consolidation of values:
$required  = array('required' => true);
$asterisks = array('invalid'  => '**************.');
...
'domain_name'   => new sfValidatorString($required),
'domain_url'    => new sfValidatorAnd(
                     new sfValidatorUrl($required, $asterisks),
                     new sfValidatorCallback(array('callback' => array($this, 'checkDomainUrl')), $asterisks),
'domain_status' => new sfValidatorBoolean($required,), array('required'  => 'Domain status is required.')

But I think all this really shows is that there's a variety of tastes, and there's often room for improvement either way.

Quote:


Now, it's not as clear as YAML, but YAML has its own drawbacks. Namely, I'm comfortable with PHP syntax, but still (to this day) not comfortable with some of the more advanced syntax of YAML. If there were ever a YAML of the form framework, I'd just want it to generate the PHP for me so that I can do my more advanced features after getting off to that a headstart via YAML.


My take is that the complex part of YAML is similar enough to JSON that it's not a big deal, since these days you really need to know JSON. But then, I've always been in the camp that says that being multilingual is a good thing.
Re: is sfForm better than form helpers?, please vote! [message #63460 is a reply to message #63282 ] Sun, 19 October 2008 19:23 Go to previous messageGo to next message
GaryFx
Messages: 377
Registered: May 2008
Location: Masschusetts
Faithful Member
weaverryan wrote on Thu, 16 October 2008 12:38

Also, not that I know what your project is (I do this when necessary), but your allowing of extra fields on the last line undoes one of the most important feature of the new form framework. Namely, the fact that the forms are tied directly to the model means that, normally, the form framework prevents users from injecting extra fields that you didn't intend.

Why is that important?

I can see this being useful for debugging purposes. And I can see it helping to detect brute-force attacks. But since the extra fields are just going to be ignored - at least, I hope that's the way things work - I'm not sure what makes this particularly important. I'll admit to not be an expert on all the ways that a server can be attacked, but I'm at a loss here to understand why this is given so much weight.
Re: is sfForm better than form helpers?, please vote! [message #63471 is a reply to message #63460 ] Sun, 19 October 2008 20:17 Go to previous messageGo to next message
weaverryan  is currently offline weaverryan
Messages: 781
Registered: November 2007
Location: Nashville, TN
Faithful Member

Quote:

But since the extra fields are just going to be ignored...


Upon looking into the code further, I think you're right on with this comment. The real problem would be to set allow_extra_fields to true and filter_extra_fields to false. If you only set allow_extra_fields to true, you'll get no validation error, but your extra values will not make it into your cleaned values. Hence, as you said, no real security error there. Good call.

Quote:

Actually, I find your worse

I disagree here. However, my formatting is far from perfect also. My point here was to create PHP that would be more comparable to its equivalent YAML syntax. The code of letsbeserious seemed to lack some spacing (indentations) that would make it much more readable and much more fairly compared with its equivalent YAML that would require these spacings. I agree that giving each additional array depth its own line is not a pretty thing to look at.

GaryFx - I basically agree with what you did in the rewrite of letsbeserious's code - that's the kind of balance to shoot for.

To get back to the original question of this topic, I'd say that overall I'm much less worried about the syntax used to create the forms (we could create the same form with PHP or YAML, and if we formatted it correctly, they'd look pretty similar), but much more the point brought up by naholyr that the common tasks have been made harder. If there's a knock to be made against the form framework - that would be it for me. As I said before, I'm hoping that the evolution of the framework as well as further documentation will solve all of that. Furthermore, on the point of the YAML syntax, I think we could debate it forever, but the bottom line is that there seems to be enough demand for a YAML syntax that I'd be surprised if a plugin wasn't created to allow for it. So, I think everybody will win on that front.


Ryan Weaver
http://www.sympalphp.org
http://www.thatsquality.com
@weaverryan
Re: is sfForm better than form helpers?, please vote! [message #63485 is a reply to message #63459 ] Mon, 20 October 2008 00:36 Go to previous messageGo to next message
letbeserious  is currently offline letbeserious
Messages: 97
Registered: May 2007
Member
Quote:


$required  = array('required' => true);
$asterisks = array('invalid'  => '**************.');
...
'domain_name'   => new sfValidatorString($required),
'domain_url'    => new sfValidatorAnd(
                     new sfValidatorUrl($required, $asterisks),
                     new sfValidatorCallback(array('callback' => array($this, 'checkDomainUrl')), $asterisks),
'domain_status' => new sfValidatorBoolean($required,), array('required'  => 'Domain status is required.')





I thought about that, all you can do is to have shortener for required option.

I'd prefer something like this

<?php
$this
->setWidget('field', new sfWidgetFormInput() )->setOption('required'true)->setMessage('invalid''This field cannot be left blank');
?>


or shorter?

<?php
$this
->setWidget('field', new sfWidgetFormInput() )->required(true)->invalidMessage('This field cannot be left blank');
?>


do you find it better than current setWidgets( .. ) way ?
Re: is sfForm better than form helpers?, please vote! [message #73718 is a reply to message #63278 ] Sun, 01 March 2009 00:26 Go to previous messageGo to next message
lkrubner  is currently offline lkrubner
Messages: 297
Registered: July 2008
Location: Virginia, USA
Faithful Member
GaryFx wrote on Thu, 16 October 2008 18:10

For example, chapter one of the forms book shows
'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects))

inside the configure method of the form definition. Suppose the visual designer decides this should really be a radio button? That means the designer has to go into the form definition (ostensibly part of the Controller, not the View), and change the call.


GaryFX, that sums up my concerns as well. At my last company I argued against adopting Symfony for about that reason. I was working at a design firm where the philosophy was to maximize the amount of work that the (very smart, very talented) designers could do without needing a programmer. Symfony went against what we believed in.

On a later job, when I was freelancing, I was forced to learn Symfony. I'm now committed to it, but only because some framework is better than no framework, and there should be a standard, and it takes too much time to learn several frameworks well.

But I am uncomfortable with the loss of flexibility that using Symfony entails, and the amount of discretion that is removed from the designers hands.



Symfony Experts offers answers: http://www.symfonyexperts.com/
Re: is sfForm better than form helpers?, please vote! [message #73728 is a reply to message #62821 ] Sun, 01 March 2009 10:29 Go to previous messageGo to next message
naholyr  is currently offline naholyr
Messages: 223
Registered: June 2007
Faithful Member
What would you tell about something like this :

Expected structures
/
  apps/
    myApp/
      config/
        forms/
          myForm.yml (2)
      modules/
        myModule/
          config/
            forms/
              myForm.yml (1)
  config/
    forms/
      myForm.yml (3)

Where myForm.yml is a YAML representation of your form, and as usually (1) is merged with (2) which is merged with (3).

In the template
<?php echo sfForm::get('myForm')->renderUsing('list') ?>

sfForm just declares a static "get" function which returns the sfForm instance corresponding to the parameters defined in myForm.yml.



We now just have to define the YAML structure (which will be quite inspired from generator.yml), but does this structure would, in your opinion, fix this lack of discretion ?
With such a system, your designers will have to edit a .yml file (which is usually rather easier than a .class.php one, and they should already be used to generator.yml at least). And eventually the template .php file to change the way the form is rendered.
Re: is sfForm better than form helpers?, please vote! [message #73764 is a reply to message #73728 ] Sun, 01 March 2009 20:46 Go to previous messageGo to next message
lkrubner  is currently offline lkrubner
Messages: 297
Registered: July 2008
Location: Virginia, USA
Faithful Member
naholyr wrote on Sun, 01 March 2009 10:29

We now just have to define the YAML structure (which will be quite inspired from generator.yml), but does this structure would, in your opinion, fix this lack of discretion ?

With such a system, your designers will have to edit a .yml file (which is usually rather easier than a .class.php one, and they should already be used to generator.yml at least). And eventually the template .php file to change the way the form is rendered.



For us, that wouldn't work. Our designers could edit yaml files if we saw the benefit, but we'd rather work with HTML. Our preference, in terms of workflow style, has been to maximize the control that the designers have, and the easiest way we can do that is to keep as much as possible as plain HTML.

Of course, every shop has its own style. But a great problem that I've seen is when projects get held up because the programmers are behind schedule. I've never seen a project held up because designers are behind schedule - always the opposite, always it is the programmers who are holding back a project. I've worked at design shops where the designers were sitting around with nothing to do, while the programmers were working like crazy. So, as much as possible, we try to shift work from the programmers to the designers. I wrote about this in some detail here:

http://www.category4.com/2007/01/02/the-problem-with-php-fra meworks/



Symfony Experts offers answers: http://www.symfonyexperts.com/
Re: is sfForm better than form helpers?, please vote! [message #73770 is a reply to message #62821 ] Sun, 01 March 2009 21:24 Go to previous messageGo to next message
naholyr  is currently offline naholyr
Messages: 223
Registered: June 2007
Faithful Member
Well, for you the only way is the 1.0-style forms based on helpers.
In fact the issue is always the same : it's easy to define once for all the list of inputs (including their names, and possible values) received by controller. Once this is done, designers can start rendering the form, and developers can start the validators and the data-handling.

I'm thinking about a template-based rendering, like this :

Form
The standard 1.1/1.2 form defined in a class. Only developers will touch this one. It will include the widgets, validators, etc...
// lib/MyForm.class.php
class MyForm extends sfForm 
{

  public function configure()
  {
    $this->setWidgets(array(
      
      // input text (number 01-99)
      'age' => new sfWidgetFormInput(),
      
      // input checkbox (read agreements ?)
      'agree' => new sfWidgetFormInputCheckbox(),
      
      
    ));
  }

}


Action Template
The action template can be eventually modified by designers, but it's PHP-style, so they should not modify this often. The change has to be small then.
// templates/MyActionSuccess.php
<!-- usual way -->
<form method="post" action="">
<table>
<?php echo $form ?>
</table>
</form>

<!-- proposed way -->
<form method="post" action="">
<?php echo $form->renderUsingTemplate('MyForm') ?>
</form>


Form Template
In this file, designers must be able to render the form, field by field, exactly as they want. They can totally ignore the widgets and render the data just as wanted.
The issue here is that some things are dynamically generated :
- error messages
- field names
Those two datas must then be handled by dedicated helpers.
In this example, they'll want the "agree" field to be displayed just as decided by the system, but they want the "age" field to be a select box instead of a text-field (it could have been a Javascript gauge or anything).
// templates/MyForm.form.php

<!-- handling global form errors -->
<?php if_form_errors() ?>
<div class="errors">
Errors in the form :<ul>
  <?php foreach (form_errors() as $form_error): ?>
  <li><strong><?php echo $form_error['label'] ?></strong> : <?php echo $form_error['error'] ?></li>
  <?php endforeach ?>
</ul>
</div>
<?php end_if_form_errors() ?>

<!-- specific field, using HTML or 1.0 helpers -->
<p>I'm <?php echo select_tag(field_name('age'), options_for_select(array(
  '01',
  ...
  '99'
)), 'class=age') ?>  years old.</p>

<!-- rendering specific error -->
<?php if_field_error('age') ?>
<p class="error">Error in your age : <?php echo field_error_message('age') ?></p>
<?php end_if_field_error() ?>

<!-- standard field (including standard error inclusion) -->
<p>I read agreements : <?php echo field_render('agree') ?></p>



This is just an idea, I'm trying to understand what we could do to improve this system, and I'll may make a plugin which realizes this, before we propose something constructive to the core-team.

But as I get it, I think we need to keep the powerness of sfForm for developers, and the easyness and flexibility of the form helpers for designers.

[Updated on: Sun, 01 March 2009 21:28]

Re: is sfForm better than form helpers?, please vote! [message #73787 is a reply to message #62862 ] Sun, 01 March 2009 23:43 Go to previous messageGo to next message
lkrubner  is currently offline lkrubner
Messages: 297
Registered: July 2008
Location: Virginia, USA
Faithful Member
cokker wrote on Sat, 11 October 2008 09:31

I have a mixed opinion on sfForm. All I have read about it, it is great for standard forms. But for complex forms it is no help.



Sven, I'm curious if you still feel that way, given the increased support for embedded forms in Symfony 1.2?



Symfony Experts offers answers: http://www.symfonyexperts.com/
Re: is sfForm better than form helpers?, please vote! [message #73806 is a reply to message #73770 ] Mon, 02 March 2009 10:36 Go to previous messageGo to previous message
lkrubner  is currently offline lkrubner
Messages: 297
Registered: July 2008
Location: Virginia, USA
Faithful Member
naholyr, if that system works for you and your team, then you should go for it. You can create a plugin that overrides the default scaffolding that Symfony uses. Symfony is flexible enough that different teams can make it work for their different styles. Earlier today, on our company blog, I was talking about what we would like in a scaffolding system:

http://www.teamlalala.com/blog/2009/03/01/the-goals-of-alter native-scaffolding-systems/

For us, stuff like this:

<?php echo $form ?>

is no good.

Our designers are very talented and need to be given maximum control over the templates. So I'm planning on making a plugin that overrides Symfony's built-in scaffolding, but I'll be pushing the system in the direction of less PHP and more HTML.

But, again, Symfony is flexibe enough to enable the different styles of different teams, so if your plan works for you, then you should certainly go forward with it.



Symfony Experts offers answers: http://www.symfonyexperts.com/
Previous Topic:Symfony forms trying to set a validator for a particular sfWidgetFormSchema
Next Topic:How change URL ? Remove dir web
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software