Menu
▾
▴
Re: [amfphp-cvs] plugins in amfphp
|
From: Ariel S. <ari...@gm...> - 2010-03-09 09:08:04
|
I like the revised structure. So the hook registration would happen in the class constructor, right? some ideas: - some filters are optional, even non functional. If you look in core/amf/app/Filters.php there are some essential filters for serialization/deserialization, plus some dubious or non functional filters such as authentication. These filters could be shifted to plugins. In that way the core ones could be replaced for special purposes or temp bug fixing. For example Joey submitted a patch on the deserializing of bytearrays(correct me if I'm wrong Joey), and it will be in the next version. In the meantime, it could be a plugin. Authentication is currently non functional, so it could be thrown out and replaced by one or many plugins. We're working on something simple with Danny Kopping, but it might not be evolved enough for your tastes, so you could offer your "Allow" system as a plugin. - I'm still trying to wrap my head around actions, but I'm sure there are some plugin things to be done there - a logging plugin. Actually, I would probably do this with filters. - code generation in the service browser. It's not part of the service browser, and doesn't make sense as part of its core, but would be a nice thing to be able to integrate with it as a plugin. A filter plugin for example would have 3 functions. - your plugin class constructor, a call would look something like this: hook_manager.add_hook(GET_FILTERS, addMyFilterFunction) - addMyFilterFunction would get called when the filters are collected, and would be passed an array as parameter to which it would add your filter function. - the actual filter function myFilterFunction Then when the filters are executed, your filter is too. How does that sound? Ariel On Mon, Mar 8, 2010 at 11:11 PM, Ryan T. Graff <rya...@re...>wrote: > I'm in agreement with Joey on this one, class structure is much cleaner. > > I would like to know more about what a plug-in would do, like a use case > where: > > 1. A service is called, passing in data from the client > 2. The plug-in executes > 3. The data, (effected by the plug-in???), returns > > If I knew more 'real world' use cases than just the 1 I've run into I > could help make a more productive assessment. > > RTG > > > > On 3/8/2010 12:00 PM, Joey Parrish wrote: > > On Mar 8, 2010, at 10:44 AM, Ariel Sommeria wrote: > > > > > >> Hi all, > >> We've been tossing the idea of plugins for AMFPHP around, and so here's > what come of it. Please share your thoughts on this. > >> > >> Why? > >> People who want to contribute to the AMFPHP community currently mst have > their contribution vetted by me. Not only am I a poor judge, but I'm also > lazy. So the idea is to provide a system where someone who has a cool idea > can push it to the community and let the community decide. > >> > >> Design Goals > >> Flexibilty, extensibilty, simplicity, convention over configuration > >> > >> How (global design)? > >> I've looked around a bit, and what seems to work elsewhere and that I > quite like is a system of hooks. The idea is that at certain points in the > execution of the script the possibility is given to the plugins to interact > with the data flow. Here's a simple example: Your plugin wants to add a > service to those available in the usual "services " folder. When the gateway > tries to direct a service call, instead of just routing it to the services > folder, it can ask the plugins first if they have a matching service. > >> > >> How (technical specifics)? > >> There will be a new "plugins" folder in amfphp. Each plugin will consist > at the very least of a subfolder and an index.php. When called this > index.php will register for all needed hooks. To continue with the example, > the index.php will register a function "addMyService" for the hook > "LIST_SERVICES". When LIST_SERVICES is called by the gateway, the plugin's > "addMyService" function will be called, and it will return the path to the > plugin's service. > >> > >> > > I suggest tweaking this structure a bit. > > A plugin called xyz could consist of: > > > > plugins/xyz.php > > plugins/xyz/ (optional) > > > > plugins/xyz.php would contain a class called xyz which implements a hook > registration method. The plugin could have all of it's code in the class > xyz, or it could host a variety of other things in the xyz folder if the > plugin is complex/organized enough to warrant it. > > > > The advantage of a structured class over registering functions in > index.php: > > > > 1) Because the registration lives in a class method, someone can't just > point their browser at a php file and see the registration functions failing > left and right. > > 2) For simple plugins, a folder is not needed. The plugin can be > self-contained in one file. I like that a simple plugin could be compact. > > 3) You still have a folder convention for more complex plugins to keep > resources in. This could be swfs, graphics, more php classes, whatever. > > 4) If plugins are object-oriented, each plugin's hooks have their own > namespace. plugin2::filter() doesn't conflict with plugin5::filter(). > > > > What do you think about this structure? > > --Joey > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > amfphp-cvs mailing list > > amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amfphp-cvs > > > > > > > > > > E-mail message checked by Spyware Doctor (7.0.0.514) > > Database version: 6.14510 > > http://www.pctools.com/en/spyware-doctor-antivirus/ > > > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > amfphp-cvs mailing list > amf...@li... > https://lists.sourceforge.net/lists/listinfo/amfphp-cvs > |
