Closer To The Ideal

Some of the more interesting things I write nowadays seem to get posted in discussions on LinkedIn. I repost here what I wrote in response to someone who wanted to know how big the Symfony community is.

Everything I’ve seen and heard suggests to me that the Symfony community is small and stagnant. Consider this graph.

Drupal and WordPress are both much, much larger than Symfony. More so, according to that graph, Symfony’s growth is limited compared to WordPress.

If you remove Drupal and WordPress, then it appears that Symfony is roughly the same size as Zend and CodeIgniter, and all of them have relatively flat growth. Consider this graph.

Of course, Google Trends is only one source of information, and only offers a rough approximation. It is important to check other data sources. So, for instance, we can double check the trend by looking at Indeed: consider this graph.

Here we see that the trend to Drupal is both much greater than Symfony, and also growing at a much faster rate.

This also interesting, comparing Symfony, Zend, Cake and CodeIgniter: consider this graph.

In this, the big winner is Cake, with Symfony coming in 2nd.

There is also the experience that Darren Hoyt and I have had trying to launch our 2 sites. Consider the high levels of activity on our WordPress site compared to the low levels of activity on our Symfony site:

http://www.wpquestions.com/

http://www.symfonyexperts.com/

Symfony Experts is newer, but we put far more effort and money into marketing it than we did with the WordPress site. Yet it still lags.

Also, consider that Symfonians.net is basically the official membership site for Symfony, yet it has less than 3,000 members:

http://symfonians.net/

It is like a rounding error when compared to Drupal.

Finally, there is my own experience on LinkedIn – I constantly get calls from headhunters who call me because I know Symfony, and always they say the same thing – “There are not many of you Symfony programmers, I’ve had a hard time finding people for the job I’m trying to fill.”

No matter what data source you consult, the conclusion is unmistakable: Symfony is a small community, and its rate of growth is slow.

Why is this? My own theory is that Symfony brings to PHP something that PHP has long been missing: a truly professional, industrial strength, object oriented architecture that allows PHP to be taken seriously in the enterprise. However, all of the people who would be truly interested in such a framework have long ago found a home using Ruby, Java or Python. In short, the kinds of people who gravitate to PHP are exactly the kind of people who are unwilling or unable to appreciate the beautiful elegance and power of a system like Symfony. The people who need something like Symfony gravitate to other languages.

Brandon Savage has some advice for anyone learning the Zend framework:

Various frameworks out there have varying degrees of integration with one another. While an argument can be made as to whether or not tightly integrated frameworks are better or worse than loosely integrated frameworks, when starting a new framework it’s best to accept it lock, stock and barrel (in other words, accept it completely).

This isn’t always easy for developers. They have a particular problem they want to solve and often times solving it with a framework they haven’t used requires a lot of setup, a lot of learning, and a lot of banging their heads against a wall. I know for me this is true whenever I start working on a new framework or product. But this is an important component of using the framework. When we try and go around the framework, when we fight the framework, we ultimately end up doing a lot of the things that the framework is aimed at keeping us from having to do.

Embrace the framework. Once you’ve learned it and mastered it, you can go around it, fight it, and ignore it if you want. But until that point, ignoring it will only lead to more headache and frustration – especially when you discover the framework was doing something you were trying to do all along.
….

Learning a framework is much like learning a new language. Have patience for it. The reward is great – framework knowledge can be reused over and over again. Being patient and taking the time to learn means that the knowledge will be valuable, rather than being bits and pieces of a hurried experience (which is far less valuable). A holistic understanding of the framework will serve you well, as a developer.

Robert Speer has a great write up of Apostrophe:

Apostrophe is the easiest to use content management system (CMS) available to the open source community. An easy CMS means that content managers are more likely to use it, which means consumers will get better information and be more likely to follow the sites profit funnel.

For web solutions providers Apostrophe is a CMS solution that bypasses the commodity hell of Wordpress, Drupal, and Joomla by providing a unique value differentiation. Apostrophe also has the advantage of being built on an enterprise grade web framework used by sites like Delicious, Dailymotion, Yahoo! Answers, and Yahoo! Bookmarks. Symfony provides a consistent structure that encourages collaboration, and the large community of developers already familiar with Symfony mean help is available.

Over on Symfony Nerds, I wrote about Potencier’s ideas about a template engine. I just noticed that Eli White had also written an intelligent reply, well worth reading.

I’ve a new post up at Symfony Nerds. In it, I look at the implications of a RESTful architecture for Symfony. Should every module just have 4 actions, read, write, update and delete?

I agree with this: Netbeans is a good IDE for Symfony development. I think this is especially true if you, like me, also develop with JVM languages. This last year I was doing some Java/Swing and Groovy projects, so I started using NetBeans again. It has a plugin for doing Symfony work – very handy.

I’ve a new post up at Symfony Nerds. This looks at the evil of utility classes full of static methods, a vice that I’m guilty of on every project. I examine possible ways to refactor the code to get a healthier overall architecture.

Just saw this site referenced on the user mailist. Symfony-Check.org is a useful list of things to check when building a Symfony-backed website.

I’ve a new post up at Symfony Nerds, this one about the extent to which Drupal’s prominence limits the growth of PHP frameworks. I’ve seen a number of Django versus Drupal comparisons, which are a bit unfair, since they compare a framework to a CMS.

I’ve a new post up at Symfony Nerds, which looks at some of the bad coding practices which are common on some of the Symfony projects that I’ve worked on.

I’ve a new post up at Symfony Nerds. Fabien Potencier, the lead developer on Symfony, has recently introduced 2 new components related to templates in Symfony, including Twig, a template engine that will be introduced in Symfony 2.0. I try to offer an overview of the whole debate around these developments.

Tom Boutell explains some features that are hidden in his pkToolkitPlugin plugin for Symfony:

* The pkHtml class. Many projects allow users to edit content via a rich text editor. And we all know what happens if the user pastes a Word document in there: the styles of the page wind up hopelessly munged. You can use striptags(), but that doesn’t clean up the CSS, so your page is still a mess.

A common workaround is to use FCK’s “paste as plaintext” mode, which thwarts attempts to paste rich text from another program. That works, after a fashion, but it’s frustrating for users. And none of the workarounds help if the user is actively trying to enter inappropriate HTML in a misguided attempt to re-style their site… then calling you to fix it for the 500th time.

HTML Tidy can do the job, but it has a reputation for being heavy and slow.

Or… you can just use pkHtml::simplify():

I previously mentioned that the worst thing about Symfony is how under-documented Propel is. I also notice that the situation as gotten better than it was in the spring of 2008, when I started using Symfony. There are more and more examples of how to do things, for instance, a Left Join:

$c = new Criteria();
$c->addJoin(PatientPeer::DOC_ID, DocPeer::ID, Criteria::LEFT_JOIN);
$this->patients = PatientPeer::doSelect($c);

All the same, in the future, I will probably use Doctrine. It is well documented.

Alvaro Videla thinks out loud about what design patterns are implemented in Symfony:

Some of the patterns involved in Symfony are:

* Front Controller
* Command
* Intercepting Filter
* Context Object
* Two Step View
* Helper Object or View Helper
* Table Data Gateway (i.e.: ArticlePeer.php)
* Row Data Gateway (i.e.: Article.php)
* Active Record
* Single Table Inheritance

I think I stumbled upon this site last year, when I was first learning Symfony. At that time, the site was very rough. It is still in alpha, even now, but it looks like it has reached a point where it is useful. It converts SQL into the code needed for Propel.

So it converts this:

person.gender = ‘M’ AND (person.location IN (’Birmingham’, ‘Coventry’) OR person.location = ‘Manchester’) AND (person.enabled <> 0) AND person.age > 16

Into this:

$c = new Criteria();
$crit0 = $c->getNewCriterion(PersonPeer::GENDER, ‘M’);
$crit1 = $c->getNewCriterion(PersonPeer::LOCATION, array(’Birmingham’, ‘Coventry’), Criteria::IN);
$crit2 = $c->getNewCriterion(PersonPeer::LOCATION, ‘Manchester’);

// Perform OR at level 1 ($crit1 $crit2 )
$crit1->addOr($crit2);
$crit3 = $c->getNewCriterion(PersonPeer::ENABLED, 0, Criteria::NOT_EQUAL);
$crit4 = $c->getNewCriterion(PersonPeer::AGE, 16, Criteria::GREATER_THAN);

// Perform AND at level 0 ($crit0 $crit1 $crit3 $crit4 )
$crit0->addAnd($crit1);
$crit0->addAnd($crit3);
$crit0->addAnd($crit4);

// Remember to change the peer class here for the correct one in your model
$c->add($crit0);
$result = TablePeer::doSelect($c);

// This loop will of course need to be edited to work
foreach ($result as $obj)
{
//$val = $obj->getValue();
}

Very useful, since the worst thing about Symfony is how under-documented Propel is.

On future Symfony projects, I may convert to Doctrine.

There is a reason why Symfony developers are switching en masse to using Doctrine as their ORM, and that reason is the fact that Propel is badly documented. I’ve been using Symfony/Propel for a year now, and this is the most coherent explanation I’ve yet found about creating OR statements:

It is not a mistake but how propel works. I also thought that writing code like yours I will get an OR but $c->addOr() is when you want to include a rule about the same database field. By default $c->add() will overwrite the previous rules if the first argument (the table field) is the same, thus $c->addOr will make an OR statement for this field. The same is true for $c->addAnd() but you thought it works correct because by default it uses AND between fields, but the purpose of $c->addAnd is when you define different criteria for the same field and you want them connected with and AND. Also why are you using Criterion object directly?

This summer I worked on a project where some other programmer had used the Context object in the model classes. This caused ridiculous problems. For instance, to run the command line tools (such as “symfony propel:build-model”) I had to hard-code the loading of a context object into the core classes – what an ugly hack!

So I was intrigued to read of the problems that the Context object can cause in your form classes, and how dependency injection gives us an easy way to avoid needing the Context object.

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

…The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

How to redirect to original destination after login in Symfony. I recall this information was way too hard to find when I first went looking for it:

on first hit to your login action, store referer to the user session:

if(!$this->getUser()->hasParameter(’referer’))
{
$this->getUser()->setParameter(’referer’,$this->getRequest()->getReferer();
}

and then when login succedes, redirect user to stored referer with:

$this->redirect($this->getUser()->getParameter(’referer’);

Here is the stupid, clumsy way that I tried to do a LEFT JOIN in Symfony:

$query = ”
SELECT bailiwick_question.*, count(bailiwick_answer.id) AS howManyAnswers
FROM bailiwick_question LEFT JOIN bailiwick_answer
ON bailiwick_question.id = bailiwick_answer.question_id
WHERE bailiwick_question.end_at > ‘” . date(’Y-m-d h-i-s’) . “‘
GROUP BY bailiwick_question.id
ORDER BY howManyAnswers desc
“;

$connection = Propel::getConnection();
$this->questionStatement = $connection->prepare($query);

$this->pager = new statementPager(null, 10);
$this->pager->setStatement($this->questionStatement);
$this->pager->setPage($request->getParameter(’page’, 1));
$this->pager->init();

Here is the way someone much smarter than I re-wrote the code:

$c = new Criteria();
$c->addJoin(BailiwickQuestionPeer::ID,BailiwickAnswerPeer::QUESTION_ID, Criteria::LEFT_JOIN);
$c->add(BailiwickQuestionPeer::END_AT, date(”Y-m-d h-i-s”), CRITERIA::GREATER_THAN);
$c->addSelectColumn(’bailiwick_question.*’);
$c->addGroupByColumn(BailiwickQuestionPeer::ID);
$c->addDescendingOrderByColumn(’COUNT(bailiwick_answer.id)’);
$questions = BailiwickQuestionPeer::doSelectStmt($c);

A very clever trick for using a portion of the Symfony framework to respond to Ajax calls:

Now I can execute a component from the client side. The component architecture offers native View/Controller separation, and the configuration initialization brings autoloading, database access, and more. It does work perfectly, but is it fast? Speed tests show that not launching the filter chain saves about 40% to 50% of the cost of a symfony initalization. This means that you can multiply the number of requests that your server can handle by two – for very simple requests.

This looks very promising:

I recently introduced the sfFormSymfony class in the 1.3 branch, which includes this pearl of a method:

$form->bindRequest($request);

So clean, so simple. Compare that to the code necessary to do the same thing in the 1.2 branch:

$form->bind(
$request->getParameter($form->getName()),
$request->getFiles($form->getName())
);

Ugly, huh? Fabien’s term was “not ugly, explicit” (I couldn’t help but laugh at his turn of phrase).

I’ve had the good fortune to work with some truly great designers. These are people who are understand the client’s needs, who understand the users, and who naturally develop web sites that feel intuitive to the people who use the site. Long ago I learned that, when working with such designers, it was important to empower them with the code they needed, but to otherwise stay out of the way. In particular, such designers need access to the HTML of the site. When I hide the HTML away inside of PHP functions, I’m limiting the ability of these maestros to perform.

This has implications when working with a framework like Symfony.

A lot of computer programmers would add an image to a Symfony template by using one of the image helpers:

<?php echo image_tag(’banner.jpg’) ?>

But what if the designer needs to add a CSS class to this? What if they are working late at night, and they are unable to reach me? Or they are working in the middle of the day, but it is a day I’m spending away from my computer?

The designers I work with can read PHP code fairly well. And they can look up the image_tag helper and figure out its syntax. But this is a big waste of their time. It takes them further into the world of programming than they should need to go.

When creating URLs in a Symfony project, it is important to use helpers. The helpers take care of figuring out what the right URL should be for things like images. The helpers allow us to develop on one machine and deploy to another server when we go live, and even if that other server has a completely different directory structure, we don’t need to change any links, because the helpers take care of all that for us. However, managing the URLs is the only thing that the helpers should do.

So we do not do this:

<?php echo image_tag(’banner.jpg’) ?>

Instead we either do this:

<img src=”<?php echo $sf_request->getRelativeUrlRoot() ?>/images/banner.jpg” />

or we do this:

<?php sfLoader::loadHelpers(array(’Url’)); ?>
<img src=”<?php echo public_path(’banner.jpg’) ?>” />

This way the URL is managed by Symfony’s helpers, but the rest of the IMG tag is still free for the designers to work with. If a designer needs to add a CSS class, they don’t need to call me on the phone and get me to do it, and they don’t have to start researching Symfony helper tags, instead they just add the CSS class like they always have:

<img class=”header” src=”<?php echo public_path(’banner.jpg’) ?>” />

This is an important bit of project management. It allows for a correct separation of concerns – the designers get to focus on design, and the programmers can focus on the programming.

(I’ve previously written a post where I tried to take Martin Fowler’s essay and change some of the examples into PHP.)

Fabien Potencier writes:

During the first five articles of this series on Dependency Injection, we have progressively introduced the main concepts behind this simple and useful design pattern. We have also talked about the implementation of a lightweight PHP container that will be used for Symfony 2.

This looks like a series worth reading, especially as a glimpse of the future of Symfony:

• Part 1: What is Dependency Injection?
• Part 2: Do you need a Dependency Injection Container?
• Part 3: Introduction to the Symfony Service Container
• Part 4: Symfony Service Container: Using a Builder to create Services
• Part 5: Symfony Service Container: Using XML or YAML to describe Services
• Part 6: The Need for Speed

When creating software, you can get the greatest performance speed by getting rid of any framework and writing arbitrary, ad-hoc code that suits the particular problem you face today. But, of course, such code quickly becomes an unmanageable nightmare, which is why so many of us use a framework. But frameworks are slow. Having a formal system of dependency injection adds another layer of abstraction, providing greater flexibility, but even worse performance. Given that traditional trade-off, this sounds absolutely amazing:

How can you have the best of both world? That’s quite simply. The Symfony Dependency Injection component provides yet another built-in dumper: a PHP dumper. This dumper can convert any service container to plain PHP code. That’s right, it is able to generate the code you could have written by hand in the first place.

[Update: I've re-written this post to take into account the information that Javier Eguiluz posted in the comments.]

[Update: Jacob Coby points me to Google Trends, which offers the visuals for the numbers that I quote below.]

TIOBE only tracks computer languages, not frameworks. I’m interested in how Symfony compares with the other PHP MVC frameworks. Borrowing the search idea from TIOBE, I just ran these searches:

symfony

codeigniter

cakephp

drupal

The results (how many hits on Google):

Symfony – 6,270,000 (3,900,000 for ‘php’ and ’symfony’ together)

CodeIgniter – 748,000

Cake – 4,540,000

Drupal – 28,500,000

A comparison: Ruby On Rails: 12,600,000

Meanwhile, WordPress blows away everything else: 295,000,000

My guess is that WordPress has retarded the growth of PHP MVC frameworks. The 80/20 rule applies here with some force. WordPress meets the needs of most people who need a website. PHP allows for self-contained software, such as WordPress, which is something the world of Ruby has not seen. Ruby on the web has largely meant Ruby On Rails, which one has to be a programmer to setup and use. Designers, intelligent people who are not programmers, all such people can default to WordPress.

From the point of view of a computer programmer, the code in WordPress is fairly awful. But designers love WordPress, and it needs to be given credit for successfully creating a package that designers feel comfortable with. No designer would know how to set up a Ruby On Rails site, but most web designers know how to set up a WordPress site. And for all its limitations and flaws, it must be acknowledged as the dominant platform written in PHP. Compared to WordPress, all the MVC PHP frameworks are just a footnote.

I’m going to repeat these searches every 3 months, and see how these ranks change over time.

I seem to recall reading that Propel (an ORM written in PHP) could not handle many-to-many relationships. Perhaps I’m actually thinking of Criteria, which Propel uses for database abstraction?

Anyway, apparently Propel has a way of working with many-to-many relationships:

As mentioned in the chapter introduction, Propel’s support for many-to-many relationships involves a middle step: defining the cross-reference table in your data model, and using results to perform lookups.

Take for example, a need to relate books with the people reading them — many people reading a single book, one person reading many books:

<table name=”book_reader_ref”>
<column name=”book_id” type=”INTEGER” required=”true” primaryKey=”true”/>
<column name=”reader_id” type=”INTEGER” required=”true” primaryKey=”true”/>
<foreign-key foreignTable=”book”>
<reference
local=”book_id”
foreign=”book_id”/>
</foreign-key>
<foreign-key foreignTable=”reader”>
<reference
local=”reader_id”
foreign=”reader_id”/>
</foreign-key>
</table>

In your PHP script you will need to make use of the “middleman” cross-reference table to retrieve the related entities:

$books = BookPeer::doSelect(new Criteria());

// for every book get all readers
foreach($books as $book) {
$readers = $book->getBookReaderRefsJoinReader();
}

The code above will execute two SQL statements:

1. SELECT * FROM book
2. SELECT * FROM book_reader_ref INNER JOIN reader ON reader.reader_id = book_reader_ref.reader_id WHERE book_reader_ref.book_id = $book->getBookId()

While this method is not excessively wasteful — as performing a single select to retrieve many-to-many joined results doesn’t usually make sense — but it is also less elegant than the support for one-to-one joins. Requiring the explicitly reference of the cross-reference table is a drawback to using the very literal data modeling approach adopted by Propel (inherited from Torque).

Back in 2005 I read The European Revenge. It was published in 1973. It was written by two journalists from the Economist magazine. They made the daring, controversial argument that at some point in the near future, European car makers such as BMW and Mercedes would be able to make cars that had just as much quality as American cars.

Their daring idea is something for my generation to laugh over. I came of age in an era when it was simply assumed that European cars were naturally better than American cars. Over the course of 30 years, the reputations of the various car makers had reversed positions.

Tonight, I find myself thinking daring, controversial thoughts about Ruby On Rails and PHP.

I recall in late 2005 when I first started hearing about Ruby On Rails. It was an amazing system for building big web sites much faster than anything before had allowed. I watched the video that showed how you could build a weblog system in 15 minutes. The company I worked at then hired a consultant who was also a very great programmer, a fellow who, by coincidence, had been writing about Ruby since 1999, well before most American programmers had heard of the language.

At that time, it seemed like Ruby On Rails was going to sweep all before it. PHP seemed like a dinosaur, headed for extinction. Software written in PHP was notoriously sloppy and insecure, and the programmers who worked with PHP tended to be less experienced than the programmers in almost any other programming community.

I started to study Ruby On Rails on the assumption that all PHP work would eventually disappear, and if I wanted to have a job in 2008, I’d better get with the new, new thing.

But, of course, Ruby On Rails failed to sweep all before it. It had a big impact on programming in general and on web development in particular. But of all the programming communities, Java was probably more profoundly effected than PHP. For Java programmers, Ruby On Rails lead to a re-thinking of fundamental assumptions.

When Ruby On Rails first came out, PHP was not competitive. There were no high productivity frameworks for PHP. But that has changed. PHP now has Cake, CodeIgniter, Symfony, and many other frameworks. These are all full-featured MVC frameworks, with command line scaffolding tools that automate the construction of basic CRUD forms and basic layout templates, and which therefore offer some of the same productivity gains that Ruby On Rails offers.

So much contempt has been poured in the direction of PHP that it seems normal to think it must be inferior to every other programming language. But it is worth remembering that some very good programmers have never liked Ruby:

I classify myself as one of those developers who don’t get Ruby, just like I don’t get Perl. Both are too hard for me. And there seems to be something in my brain that prevents me from learning both. It’s strange I never had the problem with C or C++ or Python or Lisp or awk.

…I just don’t like Ruby. This has more to do with how I think and work than with the true quality of the Ruby language. I’m sure Ruby is a fine programming language offering good OO features. But there is something in it that rubs me the wrong way. I tried to learn it when the first edition of the PickAx book came out. But somehow I can’t get past the “we are so OO, we write 3.abs instead of abs(3)” noise. I’m sorry. It’s not for me. There. I said it.

Most programmers first heard of the Ruby language when they heard about Ruby On Rails, so the language and the framework have always come in a bundle. If we unpack that bundle, do we find that some portion of it is stronger than the other portion? Since some good programmers dislike Ruby, yet the whole programming world has fallen in love with high-productivity frameworks like Rails, isn’t it safe to assume that Rails, the framework, is what made Ruby On Rails so awesome? That the awesomeness is clearly not tied to the language is demonstrated by the vast number of frameworks that have now been implemented in other languages. Most of these framework imitate aspects of Rails. If the awesomeness of Ruby On Rails was due to the Ruby language, then surely more programmers would be learning Ruby, rather than trying to imitate Rails in whatever language they know best. Many of these new frameworks have become successful in their own right, and have kept programmers in one language who might have otherwise converted to Ruby. Certainly, back in 2005, it seemed like there was likely to be a mass conversion of Java programmers to Ruby On Rails. That mass conversion was forestalled by the emergence of frameworks like Grails, written in a language derived from Java.

If the language Ruby doesn’t explain the awesomeness of Ruby On Rails, then that awesomeness can be captured by other languages, including PHP. I’ve been working a lot lately with Symfony, and I am impressed with the tools this framework makes available to me. Although all of the PHP frameworks had a late start, relative to Ruby On Rails, the PHP community now has a much greater diversity of frameworks to choose from, and the competition between the various PHP frameworks is likely to cause all of them to improve at a rapid rate, and also to specialize toward particular niches.

Where does that trend get us in another 3 years? Just as Mercedes went from being an inferior car to being a superior one, it seems to me that we could end up in a situation where the PHP frameworks are actually better than Ruby On Rails for any particular purpose that you can imagine.

An impressive effort: 

I was looking for a nice blogging solution for symfony, and all I found was a very simple plugin and a lot of people encouraging me to build my own blog. Even though it is a nice exercise, my philosophy is to not reinvent the wheel. Wordpress is surely the best free blogging tool available, so I preferred to spend time integrating it into my symfony application than to create yet another sfVeryEasyBlogPlugin.Integrating Wordpress into symfony can be done in three steps :

• integrating the blog into the application and its layout
• merging the authentification system
• integrating the blogging information into the symfony application

To be able to use WordPress inside a Symfony project, with an integrated login system, amounts to being able to extend WordPress with the infinite range allowed by Symfony – and that amounts to a major expansion of WordPress. The potential is great.

Symfony relies on the Propel ORM (though in the newest version of Symfony, the Doctrine ORM is given equal status). Propel does not support every field type that MySql does. After some experimentation, I found that a MySql “datetime” field needs to be represented as a “timestamp” in Propel’s schema. 

Last summer, when I was first learning Symfony, I had trouble figuring out how to do pagination in Symfony when I wrote a raw SQL query. I eventually resorted to creating database views, and then treating the views as if they were a normal database table, even to the point of creating model classes for them.

This would have been very handy, had I known it then:

Whatever you use, Propel or Doctrine, it is sometimes needed to write raw SQL queries.

$connection = Propel::getConnection();
$query = 'SELECT MAX(%s) AS max FROM %s';
$query = sprintf($query, ArticlePeer::CREATED_AT, ArticlePeer::TABLE_NAME);
$statement = $connection->prepare($query);
$statement->execute();
$resultset = $statement->fetch(PDO::FETCH_OBJ);
$max = $resultset->max;

When you do so, you loose all the relation object mapping. Besides, you cannot use any of the sf*Pager anymore.

Nevertheless, both Propel and Doctrine are based on PDO. It means that using raw queries doesn’t mean bypassing database abstraction. When you execute a query, you still retrieve a collection of PDOResulset objects, which are ‘abstract’ representations of database entries.

They’ve a useful looking new pager class listed over there.

I am dissatisfied with the HTML that is auto-generated by the built-in scaffolding system of Symfony.  I am planning to write a plugin that will generate HTML more to my liking. I know that, in the world of Ruby On Rails, there are several plugins that improve upon the built-in scaffolding system of that framework. Since these plugins have a longer history, and are more advanced, than anything in the world of Symfony, I am looking to them for some inspiration.

This is what Hobo says about itself:

It turns out that the hard part is not going fast, but staying flexible. This is where we think Hobo really shines. If you’ve played with “app builders” before, you’ll know about The Wall. The Wall is the point you reach where you have to give up and do it the old way because that one feature you really need just isn’t going to happen. Hobo doesn’t have one.

…Like Rails itself, Hobo encapsulates a number of opinions about web application development. The opinion that is most central to Hobo is this: we have found that there is a great deal of similarity from one web application to the next. Much more similarity in fact, than is supported by today’s frameworks. We would rather implement this stuff once.

Of course this approach is common to all frameworks—everything that Rails provides is there because many or all web applications will need it: database connectivity, session management, working with HTTP, etc. etc. The difference with Hobo is that we are trying to take this idea to a much higher level than is normally expected from a web framework. The ultimate goal is: don’t program your application, just declare it.

This is what ActiveScaffold says about itself:

Most web applications have many more model objects exposed on the backend, or admin side, than they do on the front. Coding interfaces for all those models is redundant and a waste of resources when all you need is CRUD functionality that’s smart enough to handle all your ActiveRecord associations.

Enter the ActiveScaffold plugin:

• An AJAXified table interface for creating, updating, and deleting objects
• Automatic handling of ActiveRecord associations
• Sorting, Search and Pagination
• Graceful JavaScript degradation
• RESTful API support (XML/YAML/JSON) baked in
• Sexy CSS styling and theming support
• More extension points than you can shake a stick at
• Guaranteed to work on Firefox 1+, IE 6+ and Safari 2+
• Released under the MIT License, the same one as Rails itself, so you can use it freely in your commercial applications.

This is what Streamlined says about itself:

Streamlined is a plugin for Ruby on Rails that provides an instant, production-ready UI for your ActiveRecord models. It started as a way to generate Administrative back-ends, but has become more general purpose and flexible over time. Streamlined aims to bring the declarative goodness of ActiveRecord to the view tier. It manages the presentation, creation, and editing of model instances, providing full-featured scaffolds equipped with everything you need to quickly and easily develop a rich user interface for interacting with your data, including:

• Zero-configuration relationship management
• Ajax-powered widgets and transitions
• Live data filtering
• Out-of-the-box sortable lists and pagination
• Exporting to XML, CSV, and JSON
• Declarative and easily-customizable UI development
• Cross-browser support including Firefox, Internet Explorer, and Safari
• Pluggable CSS styling

This gives a sense of the possibilities.

Hobo has an especially interesting goal, to create a framework that is declarative, rather than imperative.

In the short term, my goals for a new scaffolding system are simple:

1.) The HTML should use divs and CSS rather than tables.

2.) Pagination should be included by default.

3.) An administrative dashboard should be created by default.

I know I will want these 3 things from every Symfony project I start, so, for me at least, it makes sense to have  a plugin that automates all this.