Re: pre proposal question (fw for events and components)
| From: | Matthias Nothhaft | Date: | Thu, 04 Mar 2004 14:18:55 +0000 |
| Subject: | Re: pre proposal question (fw for events and components) | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-26091@lists.php.net to get a copy of this message | ||
Greg Beaver wrote:
Hi Matthias, I've also been working on an event-driven architecture for phpDocumentor 2. I wasn't planning on doing anything too complex, but was looking for a lightweight way to communicate between modules with the usual 1->1, but allow 1->many or 1->1 with listeners in between. I would definitely be interested in coordinating ideas with you on this. I guess my package itself is not really lightweight,but - in my opinion and after reading a short tutorial that still has to be written - using it is. ;-)
In my opinion, something as low-level as an event-driven component must be field-tested extensively and probably refactored at least once to be considered ready for inclusion in PEAR. I would like to avoid the mistakes made by components like the PEAR class and PEAR_Error (tieing down technology too early leads to massive BC issues and unexpected design flaws that are hard to fix later) Also my thoughts. Ok would be nice, but I think there is no need to integrate it as "the one and only component manager" - there are various ways to solve such a "project base". Maybe other devs have other solutions and it would be a good thing to be able to choose the right one depending on the project's needs.Anyway, I'm currently about to PEARify all scripts (not many scripts, but many lines...) and to fix the file and directory structure so that a PEAR::package can be build of it. And my problem is choosing a good name that doesn't block the hole category 'event and component management' !? What about 'PHP_Entercom' for 'enterprise component management', ok maybe too far away from reality, I don't know... I'd like to have a short name... I think in one or two days the time has come for a 'pre package' I still have to translate some doc comments, because starting the project unfortunately I wrote all comments in German... Hoping that there is some further feedback I'll send some links as soon as I got a working package! Regards, Matthias
Greg Matthias Nothhaft wrote:Hi all of you, I'm working on an event and component framework supporting developement of event driven component and multi tier software architecture for/in/with PHP. I wonder if you are interested to have it as an independent PEAR package before I bind functionality to "proprietary stuff" ;-) For example it could be used as start of a rapid application developement environment. What means "event driven"? This programming style affects mainly the public API of classes: Instead of calling methods directly, you send and receive messages (events) to/from the event manager. It can help making the ability of evolution of your project more future safe and can also support projects with many developers. In most web projects "event-driven components" are probably overkill, but it could be useful for large PHP projects. Please let me know if you could imagine such a "project base" as a PEAR package (and I'll prepare a "real proposal"), or if you think it doesn't fit to the goals of the repository!? I also have no idea to what category this package could fit, any suggestions? Maybe 'PHP', 'Processing' or 'Tools and Utilities'? And what name? PHP_Componentor? ;-) The framework state is alpha atm but on its way to beta: some advances features are still on the todo list, but it is already usable now. Here is a little feature list: - event, component, addon and plugin management (reads nice, what?) - flexible event concept "based on mail communication" You are free to use either an object, array or string(xml). Format will be added to an official proposal, short example:$event['to'] = "data:User"; // send it to component 'User' in tier 'data'. $event['from'] = "process:User"; // sent from this component $event['what'] = "login"; // tell recipient what to do $event['var'] = array("user"=>"matthias", "pw"=>"secret"); // any data you want to append- load-on-demand feature: components are only loaded if addressed by an event. - complex but still easy to use for developers! Examples and docs and 'phps' are in work, I just wanted to know if I should do some more to PEARify it now? Regards, Matthias