Well, Sameer and I decided in an IRC discussion that we'd use ///Name instead, but nobody is stuck on that. I'll implement it in whatever way someone has a strong opinion.... As far as the regexp, I'll use this one (just invert it) http://us3.php.net/language.functions That way we snag any valid function name.... thanks, -kz -- Website: http://darthsebulba.is-a-geek.org/ Public Key: http://darthsebulba.is-a-geek.org/Key/Darth_Sebulba05-at-phreaker-net_pub.key On Thu, January 5, 2006 12:27 pm, keith d. zimmerman wrote: > Ok, I think I followed this thread well enough. I'm not very > experienced with php, so I'll need a bit of validation for the patch I > am making. I started this patch today, and I intend to use this code to > generate the plugin function prefix from the ///Name: metadata. I was under the impression a /// UniqueName or /// FunctionPrefix was going to be used? This prevents authors from having to rename their functions if they change the name of their plugin and we wouldn't have to do the below. > preg_replace( "/^[-0-9]+|[^a-z0-9-_]/i", "", $plugin_info['name'] ) > Now Chris says that str_replace is better, and I'll use it if i can... I > can't figure out to invert the sense like I can with preg_replace, > though. (I want to replace everything other than 0-9, a-z, _ and -) > The ^[-0-9]+| part is because I believe a function name can't start with > a number (not sure of this either). That's probably the best way to do it. I was thinking something more simple of "replace all spaces and .'s with _", but /// Name is a freeform field, so anything goes.. I'm not sure how well that matches non-English characters though. > > I plan to prefix this value with a double underscore, and append > _Configuration, _Activated and _Deactivated to the end. So a plugin with > /// Name: Printer Friendly URLs > could define functions called __PrinterFriendlyURLs_Configuration, > __PrinterFriendlyURLs_Activated, and __PrinterFriendlyURLs_Deactivated > that would "magically" be called. > > Does this all make sense? I have already started work on this patch, > so I'll likely post a preliminary version to trac before too long. > > thanks all, > -kz > > > Chris J. Friesen wrote: >> On Tue, January 3, 2006 11:48 am, Sameer D'Costa wrote: >> >>> The problem with ///Name is that you can have spaces in it. so we >>> cannot >>> convert that to a function easily. >>> >> >> Just need plugin naming standards! :) >> >> Anyways, a unique key/name/field type thing might be better to do it >> while >> few plugins actually depend on it.. >> >> >>> Unless we preg-replace all bad characters (like spaces) out. >>> >> >> For future reference, str_replace is better than preg_replace. >> >> http://us2.php.net/manual/en/function.str-replace.php >> >> >>> Sameer >>> >>> >>> On Tue, Jan 03, 2006 at 11:42:39AM -0500, Chris J. Friesen wrote: >>> >>> >>>> Date: Tue, 3 Jan 2006 11:42:39 -0500 (EST) >>>> Subject: Re: [greg-dev] http://svn.gregarius.net/trac/ticket/320 >>>> From: "Chris J. Friesen" <Darth_Sebulba05 at phreaker.net> >>>> To: gregarius-dev at sinless.org >>>> Reply-To: Darth_Sebulba05 at phreaker.net, gregarius-dev at sinless.org >>>> >>>> We already have this.. it's /// Name >>>> >>>> That has to be unique. >>>> >>>> Chris >>>> -- >>>> Website: http://darthsebulba.is-a-geek.org/ >>>> Public Key: >>>> http://darthsebulba.is-a-geek.org/Key/Darth_Sebulba05-at-phreaker-net_pub.key >>>> >>>> On Mon, January 2, 2006 10:45 pm, Sameer D'Costa wrote: >>>> >>>>> Hi kdz, >>>>> >>>>> I have also been thinking about this and have come up with an >>>>> >>>> alternative >>>> >>>>> solution. I was thinking that each plugin should have a unique name >>>>> >>>> which >>>> >>>>> we could have plugin authors define in the metadat like >>>>> ///UniqueName: CoolPlugin >>>>> >>>>> and then at appropriate events the gregarius code will check whether >>>>> CoolPlugin_Config(), CoolPlugin_Activate(), CoolPlugin_Deactivate() >>>>> >>>> exist >>>> >>>>> and then call them appropriately. Since these are "meta" hooks, I >>>>> >>>> think >>>> >>>>> it would be okay to do them differently from way plugins usually hook >>>>> onto normal events. >>>>> >>>>> The only advantage that this seems to provide over the method you >>>>> outlined below is that it would make Gregarius' work, of checking >>>>> >>>> whether >>>> >>>>> this plugin was updated on the repositopry, much easier. (This is the >>>>> "Check for updated plugins" button in the admin section when you view >>>>> >>>> the >>>> >>>>> plugins table.) >>>>> >>>>> >>>>> Best, >>>>> Sameer >>>>> >>>>> On Mon, Jan 02, 2006 at 12:00:27PM -0500, keith d. zimmerman wrote: >>>>> >>>>> >>>>>> Date: Mon, 02 Jan 2006 12:00:27 -0500 >>>>>> From: "keith d. zimmerman" <lists at kdz13.net> >>>>>> To: gregarius-dev at sinless.org >>>>>> Subject: [greg-dev] http://svn.gregarius.net/trac/ticket/320 >>>>>> Reply-To: gregarius-dev at sinless.org >>>>>> >>>>>> I have in mind a patch for http://svn.gregarius.net/trac/ticket/320, >>>>>> >>>> but >>>> >>>>>> wanted to validate the design here first... >>>>>> >>>>>> It seems to me that instead of storing an array of arrays for the >>>>>> >>>> hook >>>> >>>>>> name -> functions list, we could add a third array. So we'd have >>>>>> >>>> plugin >>>> >>>>>> function name -> plugin file name -> function list, an array of >>>>>> array >>>>>> >>>> of >>>> >>>>>> arrays. The rss_plugin_hook function could then take an optional >>>>>> >>>> second >>>> >>>>>> parameter - the name of the plugin file who's hook needs calling. >>>>>> Finally, then, in admin/plugins.php we would call rss_plugin_hook >>>>>> for >>>>>> each plugin that's being activated or deactivated. >>>>>> >>>>>> This does not yet give us a way to use a standard plugin hook for >>>>>> configuration of the plugin. This is currently done with a >>>>>> ///Configuration section in the metadata, because we want to require >>>>>> some action (activate, or click configure button) before a new >>>>>> plugin >>>>>> >>>> is >>>> >>>>>> permitted to execute code. I suppose it would be nice to come up >>>>>> >>>> with a >>>> >>>>>> design for ticket 320 that resolved this inconsistency as well, but >>>>>> I >>>>>> can think of nothing. >>>>>> >>>>>> Barring any objections, i'll likely start work on a patch late this >>>>>> week. >>>>>> >>>>>> -kz >>>>>> _______________________________________________ >>>>>> gregarius-dev mailing list >>>>>> gregarius-dev at sinless.org >>>>>> http://sinless.org/mailman/listinfo/gregarius-dev >>>>>> >>>>> _______________________________________________ >>>>> gregarius-dev mailing list >>>>> gregarius-dev at sinless.org >>>>> http://sinless.org/mailman/listinfo/gregarius-dev >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> gregarius-dev mailing list >>>> gregarius-dev at sinless.org >>>> http://sinless.org/mailman/listinfo/gregarius-dev >>>> >>> > > >