Re: pre proposal question (fw for events and components)

From: Date: Thu, 04 Mar 2004 03:40:41 +0000
Subject: Re: pre proposal question (fw for events and components)
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-26082@lists.php.net to get a copy of this message
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. 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) 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


« previous php.pear.dev (#26082) next »