Been looking at what Java and .NET do in regard to event handling in web applications.

To date, most PHP apps which get into OO use a fusebox like approach, in that one script (usually index.php) is used to handle events - all things begin with index.php. That's fine but I'm wondering if there's a more generic way to do it - a class you can simple instantiate from anywhere to handle events?

About Event handling I had something similar on a C++ application that uses a GUI.

There was an Event class which is the event itself.There was an EventManager class which was the queue of events.There was a class Object that have a method called Event.Every element on the screen had an Event method.

So the code looked something like:

// Create an event and put it in the queueeventManager->Put( new Event( L_SELECT ) );

// The event is passed to the objectmyObject->Event( eventManager->Get() );

It has been past many years since I used that app, so these are far memories.

I have no idea if it can be of some utility for you,it's just a feedback from me.

pippo

AcidReign
—
2002-10-22T14:13:05Z —
#5

Harry: its ironic, I was thinking about doing something just like this, after a discussion I was having with Vincent on IRC a couple days ago.

I was actually thinking of how I could make my quick/dirty template system better, and more robust/OO ( its really just a quick hack right now )

what I was thinking of doing, will work something like this:

// class that handles any event
class MyEvent extends EventHandler {
// override the default function, which is called by the PageClass
function raise( $param_array ) )
...
return( $display ); // what will be displayed on the page
}
}
$page = new PageClass( $template_file );
$page->AddHandler( $event, new MyEvent() );
// $event is something which is actually defined in the template
$page->show(); // edit: a method to display would be helpfull too :P (havent been awake long)

ofcourse, I'm open to any suggestions

HarryF
—
2002-10-22T14:47:20Z —
#6

OK - got to rush - just splatting these (untested) classes down. Will explain more (handlers still required);

Still taking in pippo and AcidReigns comments. Certainly there could be some more efficient approach using inheritance and polymorphism. Wanted to avoid having to change existing classes though to provide "AddEvent" methods - perhaps that's where polymorphism can come in...

In my opinion, there are a few flaws floating around in an otherwise good topic.1) PHP is a scripting language with minimal support for OO. And, being an interpreted, run-time language, the good old "less-is-more" mentality has to prevail.

2) It seems that truly useful event registers would have to be implemented by the application server (PHP engine, for instance) rather than wedged in by way of some overbearing PHP classes.

3) I'm a firm believer in "the right tools for the job", and with that said, there are plenty of scripted application servers for HTTP. Dumping HTML to a browser seems - at present - a trivial task, best handled in a simpler-is-better manner.

If you're going to rethink the way things work (which is something I'm all for) you have to rethink the whole process. It doesn't make sense to reinvent one facet of app servers, only to shoe-horn it into existing methodologies.

So in other words, why not a new architecture that implements HTML-inspired events straight out of the app server?

HarryF
—
2002-10-22T18:49:27Z —
#11

Alright!

Well I agree with you on one level, although the example you give of a switch statement lacks some ingredients event handling could deliver such as the ability to have multiple events and not to be tied to expection particular named $_GET variables, for example.

What if you have two important $_GET variables plus a cookie variable you want to response to? You're talking multiple switch statements or if/elses.

I'm not saying I've got a perfect solution (probably far from it) but the idea is by wrapping up your code in a series of handlers, it could become extremely easily to reuse existing classes and handlers.

All in all, it's a result of frustration from having built applications which ended up in giant and unwieldy conditional statements in index.php

It seems that truly useful event registers would have to be implemented by the application server (PHP engine, for instance) rather than wedged in by way of some overbearing PHP classes.

Think you're right perhaps I don't think the PHP group really responds to demand but rather what they've got time for. Some would also argue that the PHP engine should be kept free of such things.

Been fooling with ezPublish alot recently, at work and at play - the current version handles events in a fairly crude way (looks for a particular filename then uses switch statements within that file) but is already excellent. You could already describe it as an application server in some senses. Version 3.0 is on the horizon and methinks it's gonna rock!

But back to the point - if Javascript can have eventHandling, why shouldn't PHP? And more to the point, as it's being done in ASP.NET...

Captain_Proton
—
2002-10-22T18:55:26Z —
#12

1) PHP is a scripting language with minimal support for OO. And, being an interpreted, run-time language, the good old "less-is-more" mentality has to prevail.

Alright here we go again... What is missing in PHP's OO support according to you??

Multiple InheritanceIs considered a bad practice in OO. A form of multiple inheritance, interfaces, can be done in PHP. It just requires your (the programmer's) discipline

Private / Public PropertiesNo property should be public anyway, it goes against encapsulation. The whole concept of private / public properties was only introduced to make it easier for programmers. Again, with discipline, this is not a problem.

Multiple constructors / function overloadingFunctions in PHP accept a variable number of parameters, so this can be done.

Static class variablesCan be done by using a function with a static variable or by using globals which are hidden from the rest of the code (with your discipline of course).

Dereferencing ($obj->getObject->function())Just use an extra variable, this is just something to make life a little easier, nothing more.

DestructorsThose are IMHO merely for when you're lazy. With a little discipline, you can just call a destructor function instead of it being done automatically.

My point is, with a little discipline, you can do almost exactly (correct me if I'm wrong) what you would do in a language like Java or C++ using objects.

It all depends on how you treat your code. Of course, you can go and break your own rules like encapsulation by accessing private properties directly, but then this is your problem, not the language's problem. I believe voostind (can I get some support from you on this? :rolleyes:) once posted that even in languages like C++ it is possible to access an object's private properties.

But we're going way off topic, so if you want to continue the PHP OO discussion feel free to start a discussion in a new thread or something.

AcidReign
—
2002-10-22T19:16:22Z —
#13

alright, I've come up with another quick & dirty, shall we say, proof of concept

now, what the example does not show, is that you do not need a template file ... you can call a [untested] show( $object ) method, that takes an object that is derived from DisplyHandler, show() then calls the display( $object ) method of the DisplayHandler, which is given the current Display instance [ $object->display( $this ); ]the Display handler can handle output in anyway it wants to ... it has access to all the values [setvalue/getvalue] and it can call the callevents() method as it wishes.

comments? suggestions? flames?

HarryF
—
2002-10-22T20:22:59Z —
#14

That looks excellent! Still taking it in but can see how you could use objects instead of templates. Really like the mechanism for adding events. Don't see right now how you respond to "user actions" though, such as index.php?view=page2.

Will have a play and see what happens...

Eric_Coleman
—
2002-10-23T00:40:17Z —
#15

Originally posted by Captain Proton - Multiple constructors / function overloadingFunctions in PHP accept a variable number of parameters, so this can be done.

Can be faked if you really need:

1) Count number of arguments, and associate them with different functions:

This probably isn't all that good of a solution, but if you must have it, you can I suppose

trickie
—
2002-10-23T03:42:41Z —
#16

I'm thinking that this is definatley a good idea for an external extension.Especially if persistance and object serialization is added.

I also have been thinking that it would be cool if you could register events with a XML-RPC or some other remote call as the handler.

AcidReign i like that code, but i think it would be better to abstract the event registering/executing stuff totally seperate from the display (although i can see how that could be a particular event) and then implement the presentation layer as events (although i already said that is kinda what you are doing)

Anyway i think that if persistance is the name of the game then it would be good to do a C extension.

HarryF
—
2002-10-23T09:14:48Z —
#17

OK - finished of the "first version" based on what I started with (attached as Zip with a mini demo site included).

At the moment it's specifically geared to the $_REQUEST global - XML-RPC etc. would require some alteration...

Also it doesn't handle multiple events well. With the demo in the ZIP, if you use "index.php?view=links&action=addComment" for example, it will look a little wierd.

Think the answer to that is rather than handlers echoing output directly, they put messages on an "event output queue" which the listener then deals with as the final step. Course when I start thinking about that, reckon this now is going too far.

The other direction to go might be using output buffering and customer error handlers - use trigger_error to activate events. Might also be interesting to use get_declared_classes() in some way - perhaps to find all the declared handlers.

Anyway - I need a break. This has all been too eventful

aivarannamaa
—
2002-10-23T09:59:23Z —
#18

Can someone please explain the purpose of events in PHP with a few senteces, what problem they have to solve? I can understand their place in the GUI side of application (in JavaScript) but not in server side. Isn't the execution of the script only event needed (and only event that happens on server)?

Aivar

HarryF
—
2002-10-23T10:53:50Z —
#19

Isn't the execution of the script only event needed (and only event that happens on server)?

Well yes but what the script actually does may vary from execution to execution, depending of things like form POSTs and links with GET variables. Perhaps this should be described more like "incoming event handling".

That's only to handle a few "incoming" events. What happens in an application where there's a lot of room for user interaction? There's other ways to write the above code, using arrays for example, which will be more compact to read but amounts pretty much to the same thing - the whole app depends on this single script being correct, even when it becomes highly complex.

The other approach to the problem is to specify particular variable names for example;

That's fine in a way, but then all your code needs to conform to this standard - often a problem in intergrating old code an different applications. Also you're generally tied to a single script (index.php) being the "traffic cop" for your application.

trickie
—
2002-10-23T11:08:51Z —
#20

I also think that it is the order of events that can make this system eventful . You could have your application respond to the an unlimited number of events in any order.

Usually if you follow the 'old' system that Harry pointed out then the order of execution of a script is hard-coded (at least to some extent). This 'new' way you could get different responses by differing the order of event execution.