• Previous message: [greg-dev] http://svn.gregarius.net/trac/ticket/320
  • Next message: [greg-dev] http://svn.gregarius.net/trac/ticket/320
  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    [greg-dev] http://svn.gregarius.net/trac/ticket/320

    A proposed patch is up at http://gregarius.dropcode.net/trac/ticket/320
    
    Thanks in advance to all who look through it and provide advice.  This 
    patch is only for the configuration part; I'm still working on the 
    Activated/Deactivated parts.
    
    -kz
    
    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.
    >  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).
    >
    > 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
    >>>>       
    >>>     
    >
    >
    
    
    Posted by keith d. zimmerman [reply] at Thu Jan 5 19:03:12 CET 2006