The Good, The Bad and the Ugly
There is a lot to learn from Fabien Potencier, the creator of the symfony framework. He often comments people's work on other frameworks, but almost never when someone works on his own framework. So his recent reaction about my DDD experiment is rare enough to be thoroughly analyzed, and distilled. Let's look for the very substance of his latest post.
The Good
It's been more than ten months since my original Forms post, about which Fabien basically told me that I knew nothing about programming (which is true) but nothing else. So I'm very glad that he finally decided to give more feedback about the ideas I suggest. My previous post asked for developers' thoughts about a reworked Chapter 10, and who could better do this than him?
Not only does Fabien talk about my DDD experiment, he actually implemented some features I suggested. Thanks to commits made to the symfony 1.2 branch early this week, building a form object using the sfForm class alone is easier. Added is the ability to define default values for each widget, the ability to iterate on a form object, the ability to directly set a widget or a validator from the from object. I proposed all those changes to make the documentation easier to read (and write), and it seems that they also have an interest for the developers.
Fabien points some mistakes I did, like the 'multiple' validator, which is a bad idea. Since there are two kinds of multiple validators (on the uncleaned value and on the cleaned value), the 'multiple' keyword is not the best choice. I still thing that 'pre' and 'post' validators could get a better name, but that's a detail.
Also, the modified version of my proposed Chapter 10, published as an attachment to Fabien's post, keeps about 90% of the original text unchanged. It seems that he disagrees mostly on some technical details, and didn't touch the order in which things were introduced, nor the length of the Chapter.
The Bad
But the idea to define form widgets and validators based on an associative array got no credit to his eyes. It is probably a matter of preference; I introduced this array syntax for two reasons:
- To avoid introducing too many classes too early in the documentation
- To make the YAML form definition syntax completely natural
To my eyes, this array syntax has always been a layer on top of the existing syntax; that means that the ability to define custom widgets and validators is still there, and the ability to pass an object instead of an associative array is still there as well. That's how I tried to remove the coding style preference problem: whatever you like more, symfony supports it. You get both simplicity of use and power.
"[The suggested API] is not shorter, it is not easier to understand, and it is more difficult to explain.". Let me respectfully disagree. It is shorter, easier to understand, and easier to explain. Compare what a single chapter explains and the confusion introduced by an unfinished and lengthy book. Or better, compare:
<?php
class ContactForm extends sfForm
{
protected static $subjects = array('Subject A', 'Subject B', 'Subject C');
public function configure()
{
$this->widgetSchema->setNameFormat('contact[%s]');
$this->widgetSchema->setIdFormat('my_form_%s');
$this->setWidgets(array(
'name' => new sfWidgetFormInput(),
'email' => new sfWidgetFormInput(),
'subject' => new sfWidgetFormSelect(array('choices' => self::$subjects)),
'message' => new sfWidgetFormTextarea(),
'file' => new sfWidgetFormInputFile(),
));
$this->setValidators(array(
'name' => new sfValidatorString(array('required' => false)),
'email' => new sfValidatorEmail(),
'subject' => new sfValidatorChoice(array('choices' => array_keys(self::$subjects))),
'message' => new sfValidatorString(array('min_length' => 4), array('min_length' => 'Your message is too short')),
'file' => new sfValidatorFile(),
));
$this->setDefault('email', 'me@example.com');
}
}
?>
And:
# in YAML
&subjects: [Subject A, Subject B, Subject C]
name_format: contact[%s]
id_format: my_form_%s
widgets:
name: text
email: { type: text, default: me@example.com }
subject: { type: select, choices: *subjects }
message: textarea
file: file
validators:
name: { type: string, required: false }
email: email
subject: { type: choice, choices: *subjects }
message: { type: string, min_length: 4, errors: { min_length: Your message is too short } }
file: file
According to Fabien, using associative arrays to make the YAML syntax easier to explain is of no use, since YAML is bad and shall be dropped altogether. "Learn from our mistakes" means that symfony should never had used YAML in the first place, despite the fact that it appealed numerous users to it and that it's only a simplicity layer. That means that the symfony 1.2 admin generator will not be controlled from a YAML file at all - defining form widgets in YAML is an indispensable brick to a YAML syntax for an administration interface. So be prepared to use XML or plain PHP for your database schemas, configuration files, generated modules, etc.
"Learn from our mistakes" also means not using strings to define HTML attributes anymore. I suggested to keep on using the abilities of symfony 1.0 to output clean XHTML attributes from a string looking like 'id=contact_subject class=bar'. But that is something else you should forget about. Apparently, this brings no benefit over array('id' => 'contact_subject', 'class' => 'bar'). Once again, I can understand it's a matter of preference, but I'm convinced that this kind of syntactic sugar is what appealed many users to symfony in the first place.
In the documentation I wrote, I introduced a way to bind a form object to the request object ($form->bind($request)). I explained later in the chapter why it's better to do otherwise, but at least it shows that a form can be used without necessarily using the array syntax for widget names. Fabien explains why this is wrong (as I did) and fails to see the interest of introducing the setNameFormat() in the documentation only when it becomes necessary. However, the current symfony book uses this technique several times (think of in Chapter 2 for instance), because it is easier to know why a practice is wrong once you've seen the advantages of the good practice in comparison. His revised version of the Chapter 10 doesn't solve the problem, either.
But honestly, I don't care much about all these points. If if was just for Fabien's remarks on the technical side of things, I'd be more than willing to continue working on a modified Chapter 10 to make it worthy of The Guide.
The Ugly
But Fabien is really going to a nasty place with his post.
Does he bring a response to my request for comment? No, he replies to a commenter of my post, who challenged him to give his opinion. He never actually addresses me directly - I'm a persona non grata.
Does he agree on the DDD experiment? Of course not, DDD is the "Biggest problem" according to him (not sure why). How could documentation and teaching influence a developer's design decisions? The forms API is "good enough" as is, and its lack of documentation is not a problem to be solved by modifying the code. If someone (but not me) wants to write something to "help us improve the current documentation", he can still try again.
Is he grateful that I did in a week a work (Chapter 10) that he couldn't do in a year? Not at all. Not a word of thanks, he just feels insulted that someone dared to question parts of his work. What a childish reaction to someone who offers to help widen the symfony adoption.
Does he react in the interest of the community, proposing to use his own version of the Chapter 10 for the current guide? Not even that. He prefers no documentation at all rather than an equivalent to the symfony 1.0 documentation updated for symfony 1.1.
Does he care about the newcomers to symfony, those who don't know the 1.0 API by heart, don't follow the Trac timeline every day, don't read the framework code, and don't accept an UPGRADE text file for a documentation? No. Not a word about them in his post. Only the developers who already know good practices of web development can start using symfony. You can no longer learn these practices by learning symfony.
Does he write that he's been implementing some of my ideas? No, that would be giving me too much credit. The goal, here, is to show that I am a bad developer, and nothing else. Well, I'm not even a developer, so why all the hate?
Is he trying to be constructive? No. He writes, in bad faith: "[Francois'] API is so unintuitive that we must explain a lot of things to describe the way it works". God, I thought that I managed to explain in 1 hour what he needs a day to teach in an expensive training, and it's my API that is unintuitive?
Conclusion
All in all, Fabien reacts with pride rather than reason. He does as much as he can do discredit my work, while my purpose has always been to help leverage the symfony adoption. He probably dreams that, with a single blog post, I'd leave the symfony community completely, because he finally demonstrated that none of my work is worthy to his eyes.
Too bad, Fabien, you have taken the wrong path. I'll be a pain in your ass for a long time. Count me in to constantly remind people that symfony is a one-man work, and that this is a very high risk for enterprise projects, given the man.
Possibly related posts (automatically generated):
Hi Francois,
As always, your criticism on the framework and API has been helpful of the framework and has been pointing out valid points. Even though I do not agree with all of your points, it's good to have someone point them out so people start thinking about them. You have always been very clear in the fact that you do this for the benefit of the community and the framework, and I respect that.
But your conclusion breaks with the intention you've always been communicating to everyone. And there are two single lines that actually go against that all so clearly that it actually damages the framework and the community:
"Count me in to constantly remind people that symfony is a one-man work, and that this is a very high risk for enterprise projects, given the man."
These two lines - when read by the right people - may mean the difference between a company chosing symfony or another framework. They may cause many serious developers to take the framework less serious. And even though you say you don't want to leave the community, by putting things this way and going the negative path, the community may not appreciate your work and criticism anymore. I for one - though I respect your previous work - am far from pleased by this response.
"my purpose has always been to help leverage the symfony adoption"
Please re-read your posts on this blog!
Oops, your RSS feed just suddenly quited my aggregator.
Last, just don't talk about pride and childishness, PLEASE. Not you.
Why do you write such things ?
I am a beginner with symfony and I am waiting for the 1.2 admin generator. I read you post about forms and the one from Fabien. I like both but I think Fabien his right from a development point of view.
Both syntax are easy to understand.
At least, with you different points of view, you help the community grow by having users react and provide new tutorials.
Please continue your great work on plugins !
I'm still thinking that this kind of post is the worst way to promote symfony.
Interesting post especially the conclusion.
I do not agree on the "one man work" & "high risk for enterprise" though, the licence of symfony is flexible enough do change whatever you don't like.
Pleazzzz everyone stops attacking françoiszzz, he's my idol, i got a poster of him on my wall, everytime he writes a post, it's like The new revelation for me, i drink every word flow out of his wonderful brain, his blog represents to me The Internet and i agree if someone can redo The Internet, it's him ! So yeah françoisz go on !! do it !! continue on this way, i like the way you are, let's break the community, let's fire the book, behind our computers we are all so powerful, we can even insult people without any consequences huahuahuahuahua ! (bush u noob!) <- you see huahuahua
Thanks guys (both François & Fabien), your latest posts remember me that there are humans beyond technology. But sorry, I don't feel very confortable when discussion reaches trolls and sandbox fights.
So maybe you should have a beer together to try to fix your private issues and let the community outside of this.
Such a poor way to make things evolve... Flames and free attacks won't help the community...
Your DDD attempt was great, but hey, you mean i have to learn a whole new set of arbitrary array syntax? Just because you can't write PHP and prefer a non strict unvalidable YAML file?
Too bad, François, you have taken the wrong path.
And insults you're shouting at the community confirm this.
Sad post.
Please François, just cool off. You make(made?) great stuff for symfony, don't act like this, you are destructing symfony and, moreover, your reputation.
I stay on the impression that you are, as Fabien (evil twins ?), totally indispensable. Just try not to make your ideological opposition a vulgarus trollus.
Please, François, don't continue this way ...
I think both posts are sad. I think Fabien's answer to the new chapter 10 was good on the technical point of view, but really bad from the human point of view.
It looses most of its credits from those personal attacks.
Also, François' answer is quite more calm, but slips in the end..
Allez les gars, faut arrêter de craquer comme ça, comme dit plus haut allez boire un verre dans un bistrot, rappelez vous que symfony, c'est pas la vie, c'est juste une passion dans laquelle vous vous investissez peut-être un peu trop personnellement. Prendre du recul, ça peut faire du bien quelquefois.
Si vous ne le faites pas pour vous, faites le pour la communauté. Personne n'a besoin de ce genre de réactions, d'un côté comme de l'autre.
En vous souhaitant une bonne journée...
Seriously, one thing that drove me away from the opensource community where posts like this.
If you have a discussion fine. If you dont win that discussion.. well, shit happens. If you make a post after that on the internets whining how bad the other one is, stating that you will take revenge... well, lets say: not realy grown up, and annoying to those people who just want to work on something cool.
This problem is not a symfony problem but a php one
PHP : powerful, easy to learn but a lot of people don't know good practice then there is a lot of bad site and small number of good one that make PHP a amateur language
Symfony is a good framework, make it to easy and a lot of people who don't know programing wanna use it and make a lot of horrible thing with it.
But in other side make the framework for l33t is not a good thing.
You are free to fork the project if you are not agree with the current development. It will be more interested to read your forked code than this post.
Anyway thanks for your help on sf1.0
I completely agree with Piwai. I liked the way you did things and the Fabien way. It's a pity that you can't agree with nothing. I think both chapters are fine but it'd be nice both of you to work together to make symfony better.
I think that François has a right to post his opinion. Even someone can't bear it.
I agree with him in a general point.
1 - IMHO, Francois must be in the next season of HEROES.
2 - Why you keep saying you are not a developer?? I think I need to read the concept once again.
3 - Think you are more like an engineering because you give excelent and innovative solutions to commom problems (Who else could imagine DBFinder???)
4 - A lot of people I know start using symfony because of the simplicity, and the way Fabien and others are leading the development is making me consider a completely dumb. I'm not as bright as Fabien so maybe I wouldn't be able to use sf1.2 (BTW thas was a sarcasm)
5 - Keep the great work Fraincois!!!!
I knew nothing about programming (which is true)
I think it's about time someone disagree with you on this. You certainly do know a thing or two about programming. DbFinder is a great bit of work, something that someone who is not a good programmer could not have come up with.
One more comment, if I may. I generally agree with Jerome when he says:
maybe you should have a beer together to try to fix your private issues
Whatever the claimed intentions on either side, this all seems to be too personal.
hey francois please just fork symfony. if you can't be heard, do it. the more I think about it, the more I think you are a true developer and you can make something really awesome just using the existing symfony 1.0 codebase, which is already really great as is. I don't like the way symfony 1.1 and 1.2 takes. maybe you haven't the time to do it but please consider it seriously just a minute. maybe by forking you could just implement the features the way you want to, and everybody here would be quite happy for sure.
thought once more....
and then i agree...
"maybe you should have a beer together to try to fix your private issues"
A great quote by Linus Torvalds, another famous developer (in practice):
“Talk is cheap. Show me the code.”
Really. Just fork the code for us all to see where it leads.
My 5 cents is that symfony is now suffering a bit of second system effect: a lot of features, which as of now create quite a bit of a mess. Here, you have YAML. Here, well, it's too complex, let's drop it and have XML; or just straight PHP.
Maybe it's good but wth, it's hard to tell what to use in each case. It needs to get sorted.
I think that it will get really sorted out — that is, there will be a unified way of dealing with things — in either 1.3 (which I doubt) or 2.0 (which sounds more true to me). It's just because everyone's got to get all ass pains from the second system featuritis, throw away everything that was causing the pain and have an elegant system back (the third system effect).
You cannot caution against that, it happens, and it must happen and we all (all who are concerned to an extent) must live through it. It's like your teen years which you must live through, with some mistakes awfully predictable and just as awfully inevitable.
But hey, most of us finally managed to grow up...
Or not?
Hi all,
ouch! For once you guys start debating an issue so the community can make up their own mind, and then you have to burn bridges in "the ugly"?
I think both of you are getting hung up on details, and most of those details can be solved by a simple helperfunction here and there.
On a larger note, why all this fuss about a sub-framework (just the forms) that to me looks exactly like the Zend Framework. Might as well do it exactly the Zend way, thereby opening Symfony up to Zend folks who are fed up with with their lack of a community like ours. For the record, I don't see anything Zend brings to the table that Symfony hasn't been doing better all along, but at the end of the day their code is managed and ours is now shredded. Kinda sad. I'm sticking to sf 1.0 until the "process of arriving at good conclusions" is restored.
And please go have that beer!
I think we don't know everything about your private issues, but I keep on hoping it can be fixed someday...
As many other people, I was also scared of symfony 1.1 and symfony 1.2. That's because when I read about the features that symfony 1.1+ has, and I didn't understand them. One day I woke up, clean my table and it was the right day to upgrade one of my projects to symfony 1.1 (later I rather use symfony 1.2). I found many good features I miss in the symfony 1.0.
YAML's and such things are good way to start, to see, what framework can do, but they have also many restrictions.
I agree with you , Francoisz few months ago, that sfForms are too hard to learn. They was till I start using them :-).
So all of you, who are afraid of sfForms and the symfony 1.2 concept. Don't be. Just give a try.
Hi Francois
I agree with you on some technical points - having more than one way to do it is a great idea. Personally I am not so taken with YAML, but I guess that's just my preference (and autocompletion in Eclipse PDT is awesome). But perhaps new users would find your syntactic overlay easier to use.
On that basis, I agree with previous posters insofar as this could be an extension to symfony - perhaps even just a plugin. Would it even need a fork in the symfony code? - from a quick think about it, I don't think so. I agree with you (and others) also about symfony needing a bit more democracy at the top, for the good of the project.
However some of the other issues - such as gratitude from Fabien - are personal, and are perhaps dealt with privately. Here in England we call it "doing dirty laundry in public" - which means that some things are not best done in front of everyone else! It may be that they can't be sorted out, but I guess that's life. It is frustrating to feel shut out of a project that you have contributed so heavily to, but be aware that you still have a place in the community
I'd suggest ignoring some of the rude/unhelpful comments from previous commenters, incidentally (Gunt, [MA]Pascal, etc.). Folks: criticism is fine, but let's not be rude and sarcastic - it's doesn't help!
PS keep up the great work on the plugins. I read the code to try to improve my own (who says you're not a good developer!).
For me the technical part is not that important as the criticism on the philosophie of symfony, and I go with Francois in that issue.
Symfony 1.1 is out now for a quite long time, but the documentation and the help to have an easy (as possible) entry to it are still missing.
On the one hand, Fabien is the main developer of the core and could say "hey it is open source, you are the community, I gave you a great framwork, so do the rest like documentation" but that's the wrong way!
I like most of the things that came with 1.1 and yes, I am able to understand and use the new form system, so far, but would be pleased to see the missing chapters done. 1.0 was providing simplicity on a very high level as Francois pointed out and Fabien was not able to give us users the same feeling for 1.1 at all, well, was he trying at all?
90% of all questions in the forum or mailing lists are from beginners and sould not be answered by symfony core developers, but by others who are able and willing to do so. halfer does a great job there and I myself try to help wherever I can. But the questions that are more difficult to answer (as I asked some myself) are NOT answered by anybody and that fact and the lack of documentation lets me believe that symfony right now is not developed for/by community, but of one man with his own ideas, that he will follow on. Fabien does understand any piece of code, so he has no need to document it.
So I feel, that he wants to develop new stuff that he and his company can use and that is ok so far, but new users will have their difficulties to use symfony and to get in touch so deeply, that they could provide help for core development right now, what would be the idea of open source in the end, wouldn't it?
Personally I would love to see Fabien sharing his knowledge with the community more than developing new code, and I guess thats somehow the direction, Francois wants to lead him to. The wording could be a little bit less childish and personal, though...
Wow! This is pure bitterness!
But interesting. This fall out between F&F is news to me.
Although, knowing their personality, seeing how aggressively they both tried to promote symfony... I'm not so surprised. It is very easy to get upset by the one or the other.
I'm really glad I left the sfBoat a while ago. The django community is just so much more... serene. The creators of django do not claim that they created the best framework in the universe and they don't throw stones at each other either. django is also much more the result of a community effort that a one-man's work indeed.
Still, symfony is an excellent (the best?) php framework, and I sincerely hope that those petty arguments won't do too much harm to the project.
Hi Olivier,
I was interested in your comments on the temperament of the Django community - I don't know it personally but would agree that communities tend to have their own particular flavour.
The funny thing is that I tend to see the symfony community in the same way as you do with Django: I've rather admired the fact that lead devs (Francois and Fabien in particular) have taken a "right tool for the project" stance rather than insisting that symfony should be used for everything. This sits in stark contrast to the somtimes aggressive evangelism I have seen from some other framework projects, in PHP and other languages (no names mentioned).
I don't think this disagreement ought to frighten anyone off using symfony, though I agree that it's not the best way to attract new users. Hopefully some of the comments here and elsewhere will encourage some of the difficulties to be sorted out privately.
Awwww.
And none yet managed to make these API extensions — to have the friggin' lotsa ways to do it — a plugin, whining instead on how better sf1.0 was (yeah, and the grass was greener, the light was brighter in ol' good days).
Come on. François is no developer as he admits, but the majority of the rest must be, for sure.
What about me? I kinda like the forms as they are now done. I now have them for breakfast. And for lunch, too.
(And I've had just enough Perl in the past to realize that TIMTOWTDI is a no go for me.)
I'd chip in 10 US Dollars for you two to have a beer and hash out your differences. I don't know how many beers 10 US Dollars will buy there in France, but with the US economy going the way it is that is all I can afford.
I think you are both vital to the success of Symfony. Zend is really gaining ground with its framework and partnerships with companies like Adobe. I really love the Sf framework and want to see it continue to flourish. The key to that flourishing is strong technical advantages and advancements, and great documentation. One with out the other makes no sense.
Both, please take a deep breath, resolve your differences (even if you agree to disagree - just no more throwing stones in public), and continue making Sf the best framework for PHP and the web.
"The Ugly
But Fabien is really going to a nasty place with his post.
Does he bring a response to my request for comment? No, he replies to a commenter of my post, who challenged him to give his opinion. He never actually addresses me directly - I'm a persona non grata."
http://www.symfony-project.org/blog/2008/10/12/new-in-symfony-1-2-small-things-matter-4
"Forms
The new form framework introduced in symfony 1.1 was a bit rough around the edges, and each week, we try to make it easier to use for the web designer and the developer.
This time, thanks to François's work on the documentation, we have added a way to declare widget default values and labels directly in [...]
[...] The Good, The Bad and the Ugly [...]
"The Ugly" is an unfortunate distraction from an otherwise good discussion.
I read Fabien's post, and I think the most important point was:
I finally got something I think, which I didn't get by reading the Forms book (or your revised ch. 10, Francois). Fabien envisions forms similarly to the object model, which I really like and understand. In the "standard" symfony project, the ORM layer will generate the base class for the form (propel:build-forms), based on the schema, and I will override only the things that are particular to my case. When I change the schema, add a field, etc., the ORM layer will update the base form.
I think I understand what both of you are concerned about now. From Fabien's point of view, the chapter Francois wrote is backward, because the most common and important use of the forms system (using/overriding the base class) is at the end. But from Francois' point of view, the easier stuff should come first so you understand the advantages of the "advanced usage".
So: why not rewrite the chapter to be more like chapter 8, "Inside the model layer"? I don't think the object-based form design is inherently harder to explain than the model/controller/view stuff.
I am totally committed to other projects at work this month, but if you two don't come up with some good compromise by the end of October, I will try to write or outline a chapter that maybe bridges some of the diffferences? I'm no expert at documentation or symfony, but I might be able to provide a useful neutral third party... and if anyone wants to try it before me, go ahead!
I think DDD is a great idea, by the way. I don't think Fabien was fair to call it the "biggest problem". He says he developed the form system because of practical, real-world experience, which should produce something compatible with the best results of the DDD method.
Anyway, I'm not super involved with the symfony community but I use symfony every week, I think I understand both sides of your argument, and maybe I can contribute constructively, if you don't mind.
I agree with some other posts that you guys have created a fantastic framework and come so far with it so you can't just let personal differences ruin it. I'm sure when you guys first started the chemistry was simple; just 2 guys focused on making a great framework with great documentation.
The way I see it, the documentation of symfony and the consistent evolution are what set it apart from the other php frameworks. As an advice I'd say keep the core framework simple and let the community worry about YAML, XML or PHP. Just keep it simple and focus on addressing common development issues.
I'm 100% with jérôme, you guys should go have a beer or two, we as a community don't need such a fuss, i think symfony is great but you guys really take it too seriously and forget to stay humble, remember that althought symfony is nearing the top right now, everything could end just the way it started.
Very unnice way to promote symfony, but well let's forget the last two sentences to focus on all the others
The fact is that Francois is right about the power of Symfony : the simplicity of YAML, the sintactic sugars, the easy and well-thought form validation, and admin generators. That's all the reasons that made me choose Symfony. I see no admin generator now, the simplicity of forms has been totally lost with sfForms, and when i learn that Fabien wants to get rid of YAML and the nice sintactic sugars.... I really wonder why I should keep using this framework.
Too big API, too complex. The simplicity does not require to be lost for the framework to be powerful, Symfony 1.0 is the perfect example of this.
I love Symfony, and it desperates me when I wonder if I should not look forward for other projects, or make a fork (I hate this idea) that would keep simplicity the main goal. Francois is perfectly right to alert the community that all this is not going to the right direction.
Bug well, the way is not the good one... And those last two lines are really the worst possible.
François, no new post on this blog for 3 weeks - did you meet the Sensio Crew in a dark street one of these past nights ? or did you definitively give up ?