I confirm that you must choose a prefix for your plugins and not use sf -- Fabien Potencier Sensio CEO - symfony lead developer http://www.sensiolabs.com/ http://www.symfony-project.com/ Sensio Labs Tél: +33 1 40 99 80 80
Christian Schaefer wrote: > > "Plugins are named sf*Plugin" > > I strongly advice agains this scheme! the prefix 'sf' should imho only > be used for official symfony plugins. > all other cases should use a lowercase two to four/five letter acronym > describing its creator. > > in my case this would be my initials 'cs'. > > afair fabien intended it that way anyway. > > just my two cents > /christian > > On 21 Nov., 11:26, "Francois Zaninotto" <[EMAIL PROTECTED] > project.com> wrote: >> Hi naholyr, >> >> What you describe about plugin development is a list of the best >> practices, which are not documented (yet). I'm in the process of >> writing atutorial on these points. >> >> As for publishing the plugin, ask Fabien for a commit access to the >> plugins/ directory in the svn repository (by email). Then commit the >> plugin, and create a page in the wiki with the same name (getting >> commit access to the plugins dir will also give you the right to >> create wiki pages). Then attach the pear package to this wiki page, as >> a trac attachment, and the symfony website magic will do the rest. >> Your plugin will be available for installation through the >> plugin-install command. >> >> Hope that clears things up, >> >> François >> >> 2007/11/20, naholyr <[EMAIL PROTECTED]>: >> >> >> >>> Hello, >>> I think I missed something somewhere, but I didn't find the exact >>> procedure (all in the same place) for plugin developers. >>> I'm creating a Wiki plugin (formerly named sfSimpleWikiPlugin as >>> sfWikiPlugin is already taken for a bridge project, mine is a real >>> full wiki-system for Symfony). >>> The project is fully described here >>> :http://www.symfony-project.org/forum/index.php/t/9828/#msg_num_3 >>> What I know about dev : >>> - The classes in plugins/*/lib/ are autoloadable (not the ones in >>> plugins/*/modules/*/lib/) >>> - The main module of the plugin should have the same name as the >>> plugin (sfMy for sfMyPlugin) >>> - The plugin should look at options in app_sfMyPlugin >>> - The model should be structured to be overridable by final user, >>> using an intermediat class PluginMyClass (which extends BaseMyClass, >>> and is extended by MyClass) >>> - The action has the same rule : sfMyPluginActions should be empty and >>> simply extend BasesfMyPluginActions which extends sfActions. >>> What I know about hosting : >>> - Plugins are named sf*Plugin >>> - The Subversion directory >>> ishttp://svn.symfony-project.com/plugins/sfMyPlugin/ >>> - The plugin should have a package.xml file, which allows to generate >>> PEAR package with the "pear package" command >>> - If a plugin has a page in the wiki >>> namedhttp://trac.symfony-project.com/wiki/sfMyPlugin, >>> every PEAR package attached to this page will be automagically >>> accessible via "symfony plugin-install" >>> What I don't know : >>> - How am I supposed to earn a commit access ? >>> - Did I well understand the automatic pear hosting process (with the >>> file attached to the wiki page) ? >>> - Did I miss something ? >>> - Is all this precisely documented somewhere (all the information I >>> have, I got it in mailings, forums, etc...) ? > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
