Framework apathy? Daft plugins? Blog time!
It has been a while since my last blog post, which could either be put down to long hours at work or my general apathy towards Symfony following on from Francois’ odd series of posts about the management and direction of the framework. I guess it doesn’t help that I haven’t been given the opportunity yet to let loose my Symfony skills on a client project, although I do try to keep up to date with 1.1 and the onslaught of core trunk commits. I desperately don’t want to lose interest in this framework, but my view is that there is more than enough drama on the internet and the last thing the Symfony community needs is a big split down the middle.
Anyhoo, whilst I’m in quasi-rant mode, I just thought I’d comment on the state of the plugin repository as of late. I, for one, never really understood why the ’sf’ prefix was dropped from non-core plugins, as it didn’t really do any harm. There was never any kind of quality control put in place when the devs opened their doors and invited the community to contribute, so I found it odd that people were asked to change their plugin prefixes as it clearly looked like a distancing mechanism. The equivalent of saying, “we’re really glad you felt the urge to contribute, but your code isn’t exactly up to scratch.”
I remember some discussion a while ago about a Symfony Forge for plugins, but this appears to have fallen by the wayside. There definitely needs to be a review of the plugin hierarchy, perhaps bringing it inline with PEAR’s own directory-based naming structure. Looking at the names alone, I’m stumped as to what certain plugins actually do!
The advent of 1.1 has brought about a significant change to the way in which plugins are related to each other, i.e. dependencies described in the package metadata. This is a fantastic step forward!! Alas, my own plugins have no real dependencies therefore I am unable to put this new feature to the test but the concept alone makes it worthy of mention and a smattering of praise.
July 31st, 2008 at 8:45 am
The haggis returns.
The entries by Francois are not the most inspiring things I have read, and I am lucky that all of my development work involves symfony both in house and for clients.
More cleanliness within the sf plugins can only be a good thing and will hopefully make them more of a joy to use than some encounters I’ve had.
July 31st, 2008 at 9:21 am
I’m actually loathe to use some plugins because of the way they’ve been written. Maybe it is my perfectionist side shining through, but I hate ill-thought out code and find myself unable to trust the majority of contributions as a result. A lot of the time, I just write the logic myself and package it up in my own plugin.
July 31st, 2008 at 10:24 am
Plugins, in my opinion, should represent well though out code and generally should be the best implementation of a solution rather than a quick fix. And they certainly should not cause problems themselves when being used.
July 31st, 2008 at 5:34 pm
A timely update on the Symfony website!
http://www.symfony-project.org/blog/2008/07/31/plugins-have-a-new-home
August 4th, 2008 at 10:35 am
[...] Framework apathy? Daft plugins? Blog time! [...]