Symfony Resources Central

Web development made simple

Keyword - plugin

Entries feed

sfDynamicsPlugin towards 1.0 release

By Romain Dorgueil on Wednesday, December 16 2009, 23:45 - release

It's been quite a while since the last big update, and after today's one, I decided to release 0.9.6 version (0.9.5 did not have symfony 1.4 support advertised in package.xml, so I created a new one for this).

Little sum up of new features:

  • Symfony cache is now used in debug mode too, but it checks assets modification timestamps to know if a recompilation is needed. This timestamp check is not done in non-debug mode, to avoid overhead.
  • An asset filter chain, fully configurable, extensible and backward compatible is now there. The process is pretty simple: you can write subclasses of sfDynamicsBaseAssetFilter to implement your last great idea about assets filtering. Then, just register it in your app.yml under the section sfDynamicsPlugin/concatenated_javascript_filter_chain (or the same with stylesheet). A full working example is available on the new application configuration page, that describe all app.yml configuration directives. By the way, the default asset filtair chain is exactly the same as before.
  • To demonstrate this new feature, a sfDynamicsExperimentalClosureAPIJavascriptFilter class has been added. It is an asset filter that calls the Google Closure Compiler API, via an HTTP POST request. Of course, it is not a good idea to do so on a «real» website, but this class is here for demonstration purpose.
  • Along with the new documentation page, a set of configuration values that were guessed depending on if you are in debug mode, or not, are now configurable via the app.yml of each applications. Of course, the default value is fully backward compatible.
  • Last feature, which is more polishing than a feature, is that your project won't show up if the sfDynamics module is disabled but required for some assets. Instead, an exception will explain what's missing.

All those features are tested since a few weeks, and a simple cache:clear after upgrading the plugin should keep your project in a nice state. Or at least, I hope so...

The global goal of this release is to tend towards 1.0, by making all existing features configurable and extensible, so that 1.0 branch will be able to remain stable and 100% backward compatible for a long time.

See you space symfonists!

Some sfDynamics news...

By Romain Dorgueil on Sunday, September 20 2009, 23:30 - plugin

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...







      

  


  
  

      


  

    


  The first sfDynamicsPlugin beta is out!





  By Romain Dorgueil on Monday, April  6 2009, 23:48    - release
  


  





  
After a long alpha development stage, I released this morning the first BETA
version of sfDynamicsPlugin. But... You may wonder, what is that?




sfDynamicsPlugin is a flexible assets manager for symfony which can be used to
manage javascript libraries and their associated stylesheets. It supports
packing, and CSS minifying, while keeping the full readable source in development
environment.



  

    Continue reading...
  





      

  


  
  

      


  

    


  Complex relations population in propel





  By Romain Dorgueil on Thursday, January 31 2008, 23:47    - plugin
  


  








  
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:






      

  


  
  

      


  

    


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





  By Romain Dorgueil on Monday, January  7 2008, 23:32    - plugin
  


  








  
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.







      3 comments
      

  


  
  

      


  

    


  Tired of spam? Try dkAntispamPlugin





  By Romain Dorgueil on Sunday, December 30 2007, 23:49    - plugin
  


  








  
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.







      2 comments
      

  


        

               -
            page 1 of 2          

  
  

      


        


        


      

    

    
  










  

  


  
© Copyright 2007-2009 daKrazy. All rights reserved.

  
Design, template and content by Romain Dorgueil