naholyr: Until plugins are moved to symfony-forge.com, you'll have to ask Fabien or me for that.
François 2007/11/21, naholyr <[EMAIL PROTECTED]>: > > Oh, another question, how can the plugin-maintainer make appear his > plugin in the "components" list of Trac tickets ? > > On 21 nov, 19:52, naholyr <[EMAIL PROTECTED]> wrote: > > Hmmm, you should really make the rules respected about that, because > > almost all plugins are sf-prefixed, and I think every plugin developer > > will think this is some kinda mandatory (like the Plugin suffix). > > Just take one post near mine : is b166er's plugin official ? :P > > This is so widely used that I'm sure that a plugin not prefixed with > > "sf" will be seen as some kind of draft or even a fake :( > > > > By the way, maybe we could take advantage of this post to resume here > > the best practices + the rules, and product a real doc with that ;) > > > > Note : my plugin will be then named nahoWikiPlugin but I'm really > > afraid that noone thinks this is a real plugin :/ > > > > On 21 nov, 17:23, Fabien POTENCIER <[EMAIL PROTECTED] > > > > project.com> wrote: > > > I confirm that you must choose a prefix for your plugins and not use sf > > > > > -- > > > Fabien Potencier > > > Sensio CEO - symfony lead > > > developerhttp://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 -~----------~----~----~----~------~----~------~--~---
