Question

I’m struggling to design the server-side script that responds to requests from an Ajax application.

In its current state, the app is divided into discrete pages (e.g., Orders, Items, Finances, etc.). Only when you switch between these pages does the actual webpage reload. Each page has it’s own “operator”, which is required into a root operator.php, to which all Ajax requests are directed.

Contained in each operator is this pattern:

foreach ($actions as $action) {
    switch ($action) {
    case 'get-items':
        [...]
        break;
    case 'get-item':
        [...]
        break;
    case 'update-item':
        [...]
        break;
    [...]
    }
}

The $actions are supplied by the request, e.g. operator.php?page=items&action=get-item&id=123.

As the application became more complicated, it helped to separate the logic of each action from the from context where the action was requested.

I found I would frequently use this pattern when I wanted to use an action’s logic internally in PHP:

$items = json_decode(file_get_contents('http://[...]/operator.php?action=get-items'));

(Needless to say, this design creates a lot of extra overhead.)

So instead I now have an Operator class that is extended by each page. I can create, for instance, an ItemsOperator, and directly call the action I want, without any encoding or decoding or superfluous HTTP requests:

$items = $itemsOperator->getItems();

I modified the script that responds to Ajax requests to use the Operator class, like so:

foreach ($actions as $action) {
    switch ($action) {
    case 'get-items':
        $json['items'] = $operator->getItems();
        break;
    [...]
    }
}

if (count($json)) {
    echo json_encode($json);
}

This approach works reasonably well, but I’ve never had any formal web development training, and I suspect there are established, better-abstracted patterns (which I maddeningly can’t find on Google). Numerous shortcomings with my home-brew approach inspired this question:

1. The concept of the “Operator” class that contains “actions” is too vague and all-encompassing. How should I separate the logic?
2. Where the approach gets especially messy is when I need to, for instance, search the items DB on the finances page. Do I also include the ItemsOperator alongside the FinancesOperator? (I currently duplicate the logic.)
3. Is there a better way to interface the Ajax request script with the Operator objects (assuming I shouldn’t totally dump the concept of operators)? For instance, I currently have to write a script for each page that maps the URL “action” variable to the corresponding method of the operator object.

Very sorry if this question is too open-ended. I don’t have developers around me to bounce ideas off of (and like I said, I haven’t had any real training) — so it’s invaluable to hear the advice of the SO community. When designing a script like this one, the number of possibilities/approaches/strategies can be totally overwhelming. And once you’ve invested a couple days time in one particular approach, it can be very difficult to turn back.

Thanks very much for your consideration (and reading this far).

Answer 1

Not a full answer, but I would separate operator.php into two files. One called operator.php, and the other operator_ajax.php. operator.php does what you have it doing now, but instead of echoing it, just puts into a variable so that it can be included. operator_ajax.php includes operator.php and echos the value. operator.php can then be included from any other file you wish (replacing the HTTP request).