Symfony Resources Central

Web development made simple

plugin

Entries feed

Sunday, September 20 2009

Some sfDynamics news...

Long time no see...

I'm very happy to get more and more comments and feedback about sfDynamics. I sure know it's not perfect, but seeing it's really usefull for other people than me and my colleagues is rewarding.

But I've also been so busy lately that I did very few writing and coding work around it, so I'll write about last months work, and about the future road-map.


  • I moved all my plug-ins ticketing from their different homes (lighthouse for sfDynamics, and symfony-project's trac for the others) to a brand new redmine instance I set up on trackeet.org. This will greatly enhance how I can see the issue list, prioritize and assign different stuff to people willing to help. Additionally, it helps cleaning up symfony-project's trac instance which suffers from plug-in issues since a long time.
  • I fixed the easiest issues, and they're packaged into the 0.9.4 release.
  • Since 0.9.2 release, we don't support anymore symfony 1.1, as the routing system was radically different and way less power-full.
  • After I released 0.9.4 this week, next step will be a documentation clean-up, and some tutorial writing. Yes, the fourth part is still missing, and it will come to life very soon.
  • Upcoming 1.0 release will support symfony 1.2, 1.3, and 1.4. The aim for this release is to fix all 0.9 tickets that are not radically new features. A refactoring session before the first 1.0 release will be planned.
  • Next 1.1 version will at least support symfony 1.4, and if it's possible 1.2 and 1.3 too. But the main goal will be to stick to the next LTS symfony version, which will be 1.4.

I know, no dates were given on this page, but the new roadmap page solves this.

Some more news soon...

Thursday, January 31 2008

Complex relations population in propel

Since quite a bit, I've been faced with an annoying problem on every projects I use propel on. Propel builders only generates some specific cases selection methods, which consists of pretty ugly copy paste of the same code to populate the objects, and if your needs are not satisfied by the finite little number of propel handled cases, you'll have to either use pure SQL, or write a custom doSelect method. That seems okay at first sight, but it is not. In fact, you're about copypasting the propel generated method, and that's a rude violation of D.R.Y. principle.

I found no solutions during the two last years, but maybe things will change soon with the new sfPropelImpersonatorPlugin. This plugin is aiming at doing arbitrary object population based on informations provided by propel's introspection methods (DatabaseMap/TableMap/ColumnMap) to link populated objects.

The plugin is currently in very early stage, but is working pretty well for my needs, and I'm looking forward to know what others are thinking about it.

Related links:

Monday, January 7 2008

sfForms11Plugin: use symfony 1.1 form/validation framework in symfony 1.0 or non-symfony project

The new symfony 1.1 form/validation framework is 100% symfony-independant, and though is not limited to the (very) awaited 1.1 stable release. To use it in your own symfony 1.0 projects, you can use sfForms11Plugin. It's content is very thin: it only sets up externals to symfony 1.1 form/widget/validator libraries.

To use it, simply add the following external to your project:

sfForms11Plugin http://svn.symfony-project.com/plugins/sfForms11Plugin

Or check it out from your project base directory:

svn co http://svn.symfony-project.com/plugins/sfForms11Plugin plugins/sfForms11Plugin

Let's try it...

Now you'll be able to define sfForm sub-classes to materialize forms:

class HelloWorldForm extends sfForm
{
  public function configure()
  {
  }

  public function setup()
  {
    $this->setWidgetSchema(new sfWidgetFormSchema(array(
            'name' => new sfWidgetFormInput(),
            )));

    $this->setValidatorSchema(new sfValidatorSchema(array(
            'name' => new sfValidatorString(array('required'=>true, 'min_length'=>1, 'max_length'=>50)),
            )));

    $this->widgetSchema->setNameFormat('hello[%s]');
    $this->errorSchema = new sfValidatorErrorSchema($this->validatorSchema);

    parent::setup();
  }
}

This class define the model of your HelloWorldForm, and you can now use it in your actions:

class testActions extends sfActions
{
  function executeHelloWorld()
  {
    $this->form = new HelloWorldForm();

    if ($this->getRequest()->getMethod() == sfRequest::POST)
    {
      if (null !== ($hello = $this->getRequestParameter('hello', null)))
      {
        $this->form->bind($hello);

        if ($this->form->isValid())
        {
          $this->redirect('@hello?name='.$this->form->getValue('name'));
        }
      }
    }
  }
}

At this point, the only little detail still missing is the view, containing actual form display:

<form method="POST">
<table>
<?php echo $form; ?>
<tr>
  <td colspan="2" align="right">
    <input type="submit" value="Greetings, Mr Computer!" />
  </td>
</tr>
</table>
</form>

That's it! You now have a simple form, self-validating, protected against CSRF attacks and redirecting to some place if values entered matched our sfValidatorSchema.

Sunday, December 30 2007

Tired of spam? Try dkAntispamPlugin

After last week hashbin's new release, I decided to publish dkAntispamPlugin. That's an early release, and by now it is not very feature-full, but it's doing the job we ask it, and since now, proved efficient on HashBin to make not public the pretty large amount of spam I get on it.

In One week, we got 40 messages with spam_value<10 (all checked, no spam), 14 more with spam_value<20, some of those were not spam but either inconsistent, or URL-full, 97 more between 20 and 50 (100% spam) and 498 more over this, which i'll consider as spam (don't really feel like reviewing all those).

For now, the plug-in only makes some reg-exp check, length check and URL count checks, but I'm planning in adding IP check and refining reg-exps to be less CPU eating. If any of you have anymore ideas to improve it... You're all welcome :-)

At the same time, I refactored sfGeshiPlugin to dkGeshiPlugin, to leave sf prefix for official symfony plugins, so be sure to check the wiki or documentation if you're using it.

Wednesday, August 1 2007

sfGeshi plugin

sfGeshi's aim is a symfony plugin that integrates the Generic Syntax Highlighter PHP library (GeSHi) into the Symfony Framework. Supports 75 different languages, and you can add more by writing simple php files.

Related links:

© Copyright 2007-2009 daKrazy. All rights reserved.

Design, template and content by Romain Dorgueil