Hi all, On Sat, Feb 21, 2009 at 11:34 PM, Tom Boutell <[email protected]> wrote: > A two-letter prefix of your own on filenames, replacing the sf prefix, > is very common.
Although this is a common way to name plugins, it is not the officially recommended one. Fabien's latest statement is that the prefix to be used is "sf"[1], even though he made contradictory statements in the past[2]. I personally think that choosing custom plugin prefixes is a bad choice. Right now, we have a lot of different plugins for the same purpose with varying names (sfSimpleCMSPlugin, sfSimpleCMS2Plugin, sfInstantCMSPlugin...). Mostly all of these plugins are in an unusable state. Now if we use custom prefixes as well, this situation will get worse (pkSimpleCMSPlugin, abSimpleCMSPlugin, otSimpleCMSPlugin... ???) What is really missing in symfony is a clear community guideline for developing plugins. My personal opinion on plugin development is: 1. Choose a very simple but descriptive name for your plugin (e.g. sfCMSPlugin instead of sfInstantBoosterSimpleCMSPlugin) 2. If a plugin already exists with that name (or a similar one), contact the author. In the best case, the author will agree that you work on the plugin as well. If he does not or if your opinions on the architecture of the plugin differ too much, create a new branch inside that plugin. The highest goal would be to showcase your ideas, discuss them with the community and the original author and eventually merge some of the changes that work well back into the trunk. 3. Document your code excellently, write test cases and publish good written documentation comparable to the symfony documentation. Francois held a great presentation about this on SymfonyCamp08 [3]. 4. Showcase your plugin and write about it. Write about it in blogs, publish screencasts, do everything to arouse interest. The more users you have, the more feedback you will get, the more developers might eventually join your team and help you develop the plugin. After all, plugin development is a community effort. This also means that not everything might be solved exactly how YOU want it, but how the community needs it. Splitting plugin development across multiple plugins with the same purpose but no shared effort, on the contrary, does not help the current situation. Bernhard [1] http://groups.google.com/group/symfony-devs/msg/4c47ffd08aed294a [2] http://groups.google.com/group/symfony-devs/msg/90498ce79958c591?hl=en [3] http://redotheweb.com/2008/09/15/developing-for-developers-my-symfonycamp08-presentation/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
