Hey,

I wrote some time ago I'm working on the rewriting some parts of Symfony web framework from PHP to D. One component is pretty small and is already ready. It is an Event Dispatcher:
https://github.com/caraus-ecms/caraus (submodule caraus:eventdispatcher).

Event dispatchers make it possible to write extensible applications. You can register events in different places of your application and attach callbacks to them. It is similar to signals, but you have a central instance aware of all events and callbacks (Mediator pattern: https://en.wikipedia.org/wiki/Mediator_pattern).

It isn't very useful on its own, since the event dispatcher should be passed everywhere but it can be used, for example,  with a DI container like poodinis. Since frameworks like https://github.com/Skadi-d/Skadi.d had "Event Dispatcher" in its TODO, I decided to write this Announce if something finds it useful.

In the following lines I will only describe how it works and what is for. You can find the example I describe here: https://github.com/caraus-ecms/caraus/blob/master/examples/eventdispatcher/source/app.d

We want to extend a hello world program:


import std.stdio;

class HelloWorld
{
	void hello()
	{
		writeln("Hello world!");
	}
}

void main()
{
	auto helloWorld = new HelloWorld;
	helloWorld.hello();
}


We want that people can attach their own messages before "Hello world!" or after it. We initialize the EventDispatcher in the class using it:
dispatcher = new EventDispatcher;

and then attach events like this: dispatcher.dispatch("postHello");

The last step is to register callbacks to this event:
dispatcher.addListener("postHello", delegate(Event e, string eventName, EventDispatcher dispatcher) {
	writeln("Bye!");
});


Everything together:

import caraus.eventdispatcher.dispatcher;
import caraus.eventdispatcher.event;
import std.functional;
import std.stdio;

class HelloWorld
{
	EventDispatcher dispatcher;

	this()
	{
		dispatcher = new EventDispatcher;
	}

	void hello()
	{
		writeln("Hello world!");
		dispatcher.dispatch("postHello");
	}
}

void main()
{
	auto helloWorld = new HelloWorld;

	helloWorld.dispatcher.addListener("postHello", delegate(Event e, string eventName, EventDispatcher dispatcher) {
		writeln("Bye!");
	});

	helloWorld.hello();
}


Now you should get:
Hello world!
Bye!


Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins.

Note: If someone wonder about the whole web framework I mentioned. In the last week I looked a lot into the vibe.d and I moved to its core for handling the requests instead of my own CGI-handling. I'm currently working on implementing SCGI based on vibe.d IO. And I already have a simple web page of a customer running on it (ok, it is a single page website, but it is already something :))

Enjoy. Or like people say on this forum: Destroy.

On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote:
> In the last week I looked a lot into the vibe.d and I moved to its core for handling the requests instead of my own CGI-handling. I'm currently working on implementing SCGI based on vibe.d IO


I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file:

https://github.com/adamdruppe/arsd/blob/master/cgi.d

some dox:
http://dpldocs.info/experimental-docs/arsd.cgi.html


It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy.

On Thursday, 10 March 2016 at 18:15:21 UTC, Adam D. Ruppe wrote:
> On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote:
>
>
> I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file:
>
> https://github.com/adamdruppe/arsd/blob/master/cgi.d
>
> some dox:
> http://dpldocs.info/experimental-docs/arsd.cgi.html
>
>
> It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy.

Yes, I'm aware of your code, Adam. I'm using it for reference and looking if I don't how to implement something better. Thank you for this work!

On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote:
> Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins.

How about something like MEF?

On Wednesday, 16 March 2016 at 15:14:57 UTC, Kagamin wrote:
> On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote:
>> Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins.
>
> How about something like MEF?

I didn't know about MEF before, I've just read an article about it, so correct me if I'm wrong. I think that MEF and such event dispatcher aren't comparable. Event dispatching is one of the principles how to extend the application. MEF as Wikipeda states "aims to solve the runtime extensibility problem". The important word is "runtime". So it is a higher level, it is about binding different parts of application at runtime. (As I understand it).

Now Symfony, I'm inspired by, has a thing called Bundles. Bundles are just application plugins. And event dispatching can be used inside this bundles aswell. And it is the level where something like MEF would be really great. I think it should be really done, because it would make it possible for example to write closed source plugins for open source applications (it is very common in ecommerce, for example online shops, even for PHP, where you can decode your plugins with something like ioncube).

Another area, where it could be used, is routing (already because plugins should be able to add routes to the application at runtime).

So concepts like MEF are anyway something very useful for compiled applications/languages and I'll have to find a way to implement it on some stage. Thanks for mentioning it.