"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
-~----------~----~----~----~------~----~------~--~---

Reply via email to