weUniversalClassLoaderPlugin

Want to use an Sf2 component or any other namespaced PHP code in your sf1 project? Use this plugin to make it work automatically.
weUniversalClassLoaderPlugin

weGlobalConfigPlugin

A custom config handler to bypass the crowded app.yml with some nice bonus. Not mandatory but useful!
weGlobalConfigPlugin

weErrorHandlerPlugin

Tired of finding out where that damn “Notice in file xy.php on line 1234″ comes from? Make it an exception and view the stack trace!
Sick of crappy php libraries (oh yes, php_ldap, this one goes to you) that use warnings and notices instead of exceptions? This is the past, baby, welcome to the 21st century!
weErrorHandlerPlugin

What’s the status, actually?

All the code comes as-it-is, this means:

• No (unit) tests
• Not all the functions are documented well

This shouldn’t keep you from trying it, since the usage READMEs are helpful and the code is mostly self-explaining. If you have any questions, don’t bother to ask them (probably by opening github tickets).

If you want to help (e.g. by writing tests, documentation, better code), feel free to fork and pull-request. It’s all about the code nowadays!

Have fun!

So if any of you experience a similar issue, check if the extension is present and loaded. On openSUSE systems it’s enough to install the php5-posix package. Looks like the package maintainers start to leave out stuff that hardly anyone uses anymore, which is basically a good thing. It just caught me on the wrong foot

I filed a ticket to include this in the symfony installation documentation because i couldn’t find it mentioned anywhere.

What was not so good

Altogether I liked most talks, even the infamous Microsoft one, because each single talk provided knowledge I didn’t have before. There are some general issues I want to address though:

• Some speakers had a really bad French accent. I’m glad my English was good enough so I was able to follow all of them nevertheless, but for some listeners it must have been really hard.
• Please please please provide portable headset microphones at future conferences. Speakers having to hold a microphone in their hands just look awkward, and it limits their freedom of movement and gestures. I mean, it’s not like headset mikes were ultra-future technology… This would also fix the “speaker A is much louder than speaker B because he holds the microphone too close” issue.
• The Wi-Fi connection was really bad on the first day, but it was acceptable on the second. Looks like someone didn’t realize on time that there’d be hundreds of nerds with laptops present.
• Please provide some way to get cola at future conferences, caffeine addicts will thank you for this, especially through the afternoon sessions
• The only speaker I really disliked was the second guy from the Microsoft team. If I want to be shouted at like that, I’ll visit a boot camp and insult some drill instructor, not attend a software conference!

As said above the content of the talks was fine, although there were ups and downs of course. What was much more annoying was that some speakers seemingly didn’t know much about presenting stuff. This is of course acceptable for hacking nerds in general, but only until they have to speak at conferences. Please, guys, read some books about presentation techniques in advance before giving your next speech!

What was great

Let’s stop talking about failures and continue with things that require mentioning because they were great.

• The overall organization was cool and professional. If there were any troubles behind the scenes they were kept hidden from the audience, which is fine.
• The food was good.
• The twitter visualization on the big screen was a really cool thing to do.
• The selection of talks was OK. It addressed both symfony newcomers and experienced listeners.
• The truly outstanding speakers worth mentioning were in my opinion (in order of schedule):
  • John Cleveley: this talk set the bar for the first day. Clearly audible, great presentation, interesting content!
  • Jonathan Wage: obviously an experienced speaker too, with lots of detailed knowledge
  • Stefan Koopmanschap: although the session didn’t provide much new information for me it was nice to listen to. He knows how to handle crowds.
  • Lukas Kahwe Smith: unlike his companion (don’t remember the name) he was cool, professional and easy to understand.
  • Scott Chacon: that’s what a presentation has to be like. Just like that. The reference for the second day, which was altogether definitely better than the first one.
  • Fabien Potencier: Fabien knows how to savor his fame in situations like this and he has every right to do so! What he does and how he convinces people to follow his lead is just outstanding. Standing ovations for one of the most inspiring web developers nowadays!

Symfony Live 2010 was a huge gain for myself. I met lots of interesting people and collected tons of first-hand information. Since it was the first (but definitely not the last) symfony or PHP conference I attended, future events will show how it compares.

Symfony 2 and the future

Symfony 2 will be awesome. I also checked out the brand-new Symfony 2 web page, which I recommend to everyone who is interested in PHP applications or frameworks.

It looks like phpBB 4 will be built upon Symfony 2, which I personally really appreciate because phpBB was my stepladder into PHP development and the open source community around 2001. After switching to PHP5 and OOP style programming I started to disapprove of the phpBB development style. Hopefully there will be a turn around towards more best practices in the future!

Before I forget it… the user stories

On the first day Stefan Koopmanschap announced that symfony needs more people writing success stories helping others arguing in favor of symfony. Every publishable story provided until the end of the second day would win a set of symfony books. I couldn’t resist this offer and sat through the late evening in my hotel room hurting my fingers by typing on my netbook keyboard for 4 full hours. Since I had filed similar content as my speaker’s submission (which was unfortunately rejected) I knew there was enough interesting stuff to write about. It was worth the effort: I got 3 symfony books. Thanks to the symfony team!

I don’t know when my story will be published, but I’ll link it as soon as it is. The title is “Running a TV station with symfony”.

Last but not least

Toni, I really would have liked meeting you, but it seems we just weren’t able to find each other. Let’s hope it will work next time

<off-topic> why is my WordPress editor so damn slow recently? </off-topic>

Update 2010-03-17: Running a TV station with symfony was published on the symfony blog today.

I’ve nominated symfony in 3 categories:

• Best Tool or Utility for Developers
• Best Project
• Best Commercial Open Source Project

Click the picture to nominate symfony too! Of course don’t forget to read and follow the nomination rules to allow for a fair voting process!

Have fun!

If you want to save your Wiki content and settings you just have to allow the browser to re-save the local HTML file – using that it will just overwrite itself and remember its changes when you re-open the file in the future.

TiddlyWiki is intended to be used as a single user Wiki mostly, ranging from a powerful notebook or journal to a tool to document all your work. Since it creates backup copies of its previous state upon saving, you don’t have to fear losing all your work at once in the future.

I think it is really great fun to use and marks a new step in browser based software. After playing around for a while I quickly understood how to use it and what benefits one might gain from such a tool.

Try it out for yourself and have fun!

If you happen to be in Vienna at the time we’re looking forward to your visit!

Have fun!

• Field grouping
• Field formatters
• Required marks
• Separators
• Submit buttons
• Help texts
• I18n for everything

In my current symfony project at work I’m using at least 9 different forms, tendency rising. There are lots of things that would help making most of them easier to use.

Field grouping

The W3C HTML specification provides a clean solution to grouping form fields: fieldset and legend elements. Symfony doesn’t support them by now, but I think they are crucial, since lots of people use them and they are quite easy to define.
Looking at Bernhard’s code sample let’s suppose we want to group the username and email fields and then the password fields:

  public function configure()
  {
    $this->addGroup('user_stuff', 'Personal information');
 
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15));
 
    $this->addField('email')
         ->setValidator(new sfValidatorEmail());
 
    $this->addGroup('password_stuff', 'Password information');
 
    $this->addField('password', new PasswordField());
 
    $this->addField('password_again')
         ->setWidget(new sfWidgetPassword())
         ->setValidator(new sfValidatorPass())
         ->setLabel('Password (again)');
  }

In my imagination this should render like this:

<fieldset id="user_stuff">
  <legend>Personal information</legend>
  <!-- The name and email form fields go here -->
</fieldset>
 
<fieldset id="password_stuff">
  <legend>Password information</legend>
  <!-- The password form fields go here -->
</fieldset>

The magic would be that “addGroup($name, $legendText)” would automatically close a previous group and add all further fields to the current group fieldset. To close a group manually and add the following fields to the global scope a closeGroup() method would be enough.
The grouping HTML code would be defined in the form’s formatter, which can be enhanced easily:

class sfWidgetFormSchemaFormatterList extends sfWidgetFormSchemaFormatter
{
  protected
    // other stuff
    $groupFormat = "<fieldset>\n  <legend>%legend%</legend>\n  %content%</fieldset>";
}

And what if we add a form field later on that belongs to a previous group? Nothing easier than that!

    $this->addFieldToGroup('surname', 'user_stuff');

At the end of the article you’ll see why I think it would be useful to have this in the form definition.

Field formatters

Besides the grouping my forms share one more thing: not all the fields are rendered the same way. Some of them require parameters to the label tag or just completely different row stylings. The solution to this at the moment: I have to generate the row myself. The drawback: I’m usually too lazy to include stuff like error rendering and if I change the formatter one day I have to manually alter all the custom form field rows. There’s only one summary for this: it sucks!
Why not enable custom formatters per row? There’s not even a need to define something new, we can re-use the existing formatter code!

  public function configure()
  {
//  This is how formatters are defined now:
//  $this->widgetSchema->setFormFormatterName('List');
 
//  Make it more intuitive in the first place:
    $this->setFormatterName('List');
 
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15));
 
    $this->addField('email')
         ->setValidator(new sfValidatorEmail());
 
    $this->addField('password', new PasswordField())
         // here it comes!
         ->setFormatterName('customPasswordFormat');
 
    $this->addField('password_again')
         ->setWidget(new sfWidgetPassword())
         ->setValidator(new sfValidatorPass())
         ->setLabel('Password (again)')
         // and here!
         ->setFormatterName('customPasswordFormat');
  }

The only thing that changes here is that the 2 password fields would be formatted using another formatter. Everything else would stay the same. So simple and yet so powerful…

Required marks

There have been lots of discussions on the mailing lists how required fields should be displayed. My favourite solution would be to put this where all the other formatting stuff goes: to the formatter.

class sfWidgetFormSchemaFormatterList extends sfWidgetFormSchemaFormatter
{
  protected
    $rowFormat       = "<li>\n  %error%%label%%required%\n  %field%%help%\n%hidden_fields%</li>\n",
    // other stuff
    $requiredFormat = "<span>*</span>";
}

Combined with the ability to define custom styles per field this would be a powerful solution.
Ah, there’s something else I would like to notice: defining the required property in the validator is fine from a techie-architect-point-of-view (as are so many other form related issues). But let’s once more see it from the user’s perspective:

  public function configure()
  {
    // old way
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15, 'required' => true));
 
    // what about this?
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15))
         ->setRequired(true);

See the difference? I’d personally like to have both options, but the second one would be much more intuitive from the user’s point of view.

Separators

Update 2009-04-16: I’m not sure anymore that separators like I described them here are a good idea. I’ll keep the content unchanged for anyone to understand the discussion that followed. Keep in mind that all this is a kind of brain storming which naturally results in more storm than brain .

Separators are quite useful in templates when 2 form rows shouldn’t be too close to each other or separated visually using a horizontal line or whatever. In the template this is usually done like this:

  <?php echo $form['name']->renderRow() ?>
  <div class="separator"></div>
  <?php echo $form['email']->renderRow() ?>

Let’s extend the formatter first (you know what I’m getting at, don’t you?):

class sfWidgetFormSchemaFormatterList extends sfWidgetFormSchemaFormatter
{
  protected
    // other stuff
    $separatorFormat = '<div class="separator"></div>';
}

Now we can use it in the form code. And we can use different separators in the same form!

  public function configure()
  {
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15));
 
    $this->addSeparator();
 
    $this->addField('email')
         ->setValidator(new sfValidatorEmail());
 
    $this->addSeparator()
         ->setFormatterName('anotherSeparatorFormat');
 
    $this->addField('password', new PasswordField());

Submit buttons

Submit buttons belong to the form. They are even input widgets from a technical point of view. So why not add them to the form definition?

  public function configure()
  {
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15));
 
    // all the other fields 
 
    // solution 1
    $this->addField('submit')
         ->setWidget(new sfWidgetSubmit('Submit the form'))
         ->setValidator(new sfValidatorPass());
 
    // solution 2
    $this->addSubmitButton('submit', 'Submit the form');

Together with the ability to use a specific formatter for the submit widget this would make every kind of submit button possible.

Help texts

So far the only possible way to add help texts to your form is passing them to the renderRow() method like this:

  echo $form['name']->renderRow(array(), 'Label text', 'Help text');

Why is this separated from the form definition? Especially if the label is defined inside the form? Are there scenarios where the label stays the same but the help text changes? I don’t think so!
Let’s try an alternative approach:

  public function configure()
  {
    $this->addField('name')
         ->setWidgetAttributes(array('max_length' => 15))
         ->setValidatorOptions(array('max_length' => 15))
         ->setLabel('Label text')
         ->setHelp('Help text');

You see that this is mixing content with structure. But since most of the forms stuff is mixing content with structure (otherwise the labels should never have been in the form definition in the first place) why not allow to do it properly? And this leads to my last point:

I18n for everything

Symfony is great. Symfony has many powerful features. Symfony supports internationalization (short i18n) for everything. Everything? Not so! The form classes strictly defy being i18ned (sic!), making you wrap labels and help texts in __() functions in the template and hoping that the users don’t mind english error messages. Is there a reason for this? Of course: removing the form’s dependency to use an i18n instance. Is this necessary? I don’t think so:

  public function configure()
  {
    $this->enableI18n(sfContext::getInstance()->getI18n());

Inject the i18n instance into the form. After that, everything could be translated: labels, help texts, messages, errors, even formatters! If you don’t want to use it, don’t. If you need it, make sure you get the damn i18n instance into the form somehow (there are solutions…). I know this is not easy because it changes how most of the widgets are rendered. But I think it would be worth the price.

Why do I want all this stuff?

That’s lots of feature requests. That’s lots of extensions and changes to the forms framework. But why? I can tell you! Because if all of the above features were available, 80% of my form templates could look like this:

  <?php echo $form->render() ?>

Wouldn’t that be worth it? Wouldn’t that help the core powers of symfony: KISS and DRY? I know that some projects have different people for generating form code and markup, but I think most work is done by the same developers. At least this would provide an option to do it differently.

Comments are welcome!