Fog Creek Software
Discussion Board

event-driven php web app


i know web apps are a hot topic of lately around here. so I'm asking you: how would you go and architect a web app in php but so that it is event-driven?

what i have in mind is nothing more that form entry, validation and database access. think of a bigger, more customized phpmyadmin.

i want certain actions to occur in response to certain actions (i.e. the user submitted data to a certain table). how do you do this in php or in a server-scripting language in general? (remember, php has no application server like java.)

oh, and if possible it should work without javascript.


Saturday, June 26, 2004

Generally you just give each button a name like this:

<input type="submit" name="event1" value="Do Event 1">
<input type="submit" name="event2" value="Do Event 2">
<input type="submit" name="event2" value="Do Event 2">

Then at the top of your code you have a big if statement like:

if( $event1 ) {
} elsif( $event2 ) {
.... etc

To give the illusion of events you then just need to repopulate the form controls with their previous values.

Matthew Lock
Saturday, June 26, 2004

From my understanding, event-driven apps are pretty much just message queues that allow clients to "subscribe" to certain events and a way for events to "publish" what's happening.

It's not really something that one just throws into a web app. For example, Slashdot create an "event-driven" environment which allows you to subscribe when events happen such as a user responding to your posts. However, the way they did it was by manually coding the concept of events instead of an event model. (see: ).

So basically you would need something at the core of your application which would allow parts of your app to publish events and parts of your app to subscribe to those events.

I'm not privy on PHP apps, so there may be something built in. Googling around a bit produced some interesting results. For example, here is a (cached google) article describing an authentication module built around a basic event-driven model:

Even managed to find a somewhat amicable thread about PHP vs. ASP and ASP.NET:

I'll bow out now, perhaps a PHP expert can answer if there is any progress in your arena.

Saturday, June 26, 2004

You might want to have a look at WACT:

Aaron Boodman
Saturday, June 26, 2004

thank you very much so far. i have a conrete example of what i want to do:

i display the content of a database table very much like in phpmyadmin. now the user can click on edit and the one entry is shown in editable form fields. when he submits this he is sent back to the whole table.

how do i manage the context in which the user is in? from where do i know where to throw him back to? sure i can user the tablename but i want to be more flexible.

i want to be able to show one and the same entry from two different tables or at least two different pages. and when the form is submittted the user should get back to the page where he was and that is not neccessarily the table name.

do you understand what i mean? thanks in advance for your help!

Sunday, June 27, 2004

In order to return users to the correct location I pass the return link to each page.  If I have a page displaying a table:


The links to edit each record will say:


The RET part is the URL of the previous page and contains all the necessary parameters of that page.  Returning just involves redirecting to the RET address.  It works as a stack, so can push more and more return addresses on:


As long as each level is properly URL encoded this works fine.

Almost Anonymous
Sunday, June 27, 2004

But remember that by passing application data in either GET or POST methods (by URL or by hidden form fields) you expose yourself to a potential SQL injection attack. Make sure that if you are storing the information on the client side to have some sort of validation going on.

Sunday, June 27, 2004

Not sure if this is quite what you mean, but something I've (tried to) do before in PHP that might interest you.

PHP annoys me, because I want to work with a proper web app framework and not just a bunch of separate PHP scripts. In particular I like to have URLs map to methods or functions, eg when the user calls

it returns the results of a foo() function in a suitable namespace marked as being accessible from the web in this way. You can extend the idea to do things like

where 1234 is some kind of id identifying the class instance... this automatically returns the results of calling the method on this class instance

You can sort-of write wrappers that make PHP do something like this by (in this example) having a script called 'app' in the root directory with ForceType application/x-httpd-php set in the .htaccess (something like this - look it up if you're interested). Then look at $_SERVER['PATH_INFO'] which will give you the full path requested including any higher-level bits tacked on after the /app

you can split this into components and do some security checks and then have it call appropriate methods automatically in appropriate ways, passing them the path components at a further level than the method name.
So they can either return some HTML themselves or farm the methods out to other further methods in a heirarchical way...

I'm not explaining it very well but it makes things seem a bit more elegant once the ugly work is done and lets you write code with a more event/method-based feel to it.

Sunday, June 27, 2004

Also, from another thread, here is a list of some pluggable component systems. If you're into research. :)

Sunday, June 27, 2004

What you're describing as event driven is pretty much what all web applications are guaranteed to do.  Processing takes place in response to the user triggering either a post or get event. 

To get the behavior you're describing, you have certain standard variables and a master processing function that uses the variables to decide what to do with the rest of the submitted data.  I use this model in all of my web apps and it works very well.  I tend to use variables such as "section" to determine the objects that I'll be manipulating, "action" to indicate the action to take, and "id" to indicate the particular object that I'll be manipulating.  An example of this using PHP is at

The method suggested by a previous poster of including that data as part of the URL is also workable.  Some part of the URL (at the very start) indicates the URL that you're manipulating, and additional parameters to indicate the objects in question.  You can see examples of this in action at

You can also see it, more invisible, at  That isn't a static HTML page, but a web application written in PHP that is using URL information to figure out which page to look up and render.  That isn't my dog, by the way, but she belongs to clients of mine (although she may become my dog in the near future).

Clay Dowling
Monday, June 28, 2004

PHP allows you to do it any way you want, ala TIMTOWTDI. 98% of all PHP people string togehter html/php pages with variables and php and html springing into existence at any whim.

The last couple of posters indicated that one does not have to do it like everyone else. I really like that freedom. I can do quick and dirty or I can organize my app. Imagine, I don't have to do it "only this way".

Even then though, when you begin to organize your application, you can do so for better or worse. I've seen some organized that are no better than stream of consciousness.

Design patterns help. This transcends most languages today. I've been reading the design books and so for everything I've read I can implement in PHP. It also turns out that I derived some of the same patterns, iotw, I spent the time to reinvent a wheel. Oh well.  I wish some other people had spent that time or saved time and started with patterns at the beginning.

Monday, June 28, 2004

Yes, but PHP makes it pretty hard for those who dislike the 'quick and dirty' approach. The object oriented features before version 5 are frankly a bit of a joke, it doesn't have namespaces, and because you can't (easily) get hooks from multiple URLs into one file it encourages people to churn out ten billion little PHP scripts that each do one thing. This really kills code reuse, no matter how hard you try to farm common functionality off into include files, and is an arse to maintain.

Monday, June 28, 2004

*  Recent Topics

*  Fog Creek Home