Symfony Resources Central

Web development made simple

Keyword - symfony

Entries feed

sfDynamicsPlugin towards 1.0 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!

All about backward compatibility...

Backward compatibility sounds nice, but it's not so easy to respect it in big projects. And the whole interest is on big projects: it's maybe not such a problem if your grand-ma's blog breaks its API on each release, but there would be a revolution (or not?) if win32 API was changing on each enslavement service pack microsoft releases.

Here is a real story case study of a BC break that happened on the PHP language itself.

Continue reading...

How to render a component in an action with symfony 1.1+

public function executeBarfoo(sfWebRequest $request)
{
  return $this->renderComponent('my_module', 'my_component', array());
}

This is an attempt to take over the first place on google for the query how to render component action symfony.

Towards symfony 1.1

After more than one year since symfony 1.0 was released, symfony 1.1 goes more and more mature each day. Recent RC releases are a proof of it, but many people are still concerned about whether or not they should migrate.

Continue reading...

HashBin now available in open-source flavor

Our first violin missed his plane yesterday, so Kwatuor is still not available in the upcoming unusable buggy pre-alpha (that miss all the functionalities anyway).

But while we're waiting for him to be available, I released HashBin in open-source, so anybody can dive into the code, and help me making it evolve. It still needs many attention, but hey, time is not the most available resource I have, and that's one of the two major reasons to give it to the community. Another one is that there is not so much open source symfony applications, and even less open source doctrine applications. After the doctrine 1.0 feature-freeze announcement, this could be a step to have simple sample applications (I hear little sarcastic laughs in the background...) people could dive in to learn this amazing ORM.

Well stop talking, here is the code.

SVN access is read-only for anyone, if you ever want to contribute, I'll be glad to grant you a commit access either on trunk or branch (still have to make up my mind, but at beginning that's not very important). Just ask me on IRC (hartym@freenode).

What amazing feature will you invent today?

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:

- page 1 of 2

© Copyright 2007-2009 daKrazy. All rights reserved.

Design, template and content by Romain Dorgueil