Re: pre proposal question (fw for events and components)
| From: | Greg Beaver | 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