Proper way to design a 'skeleton' script? More...

[DougBTX]

As I recall, an extract and include is actually slower than a file read and str_replace in most cases.

That's probably true for templates satisfied by str_replace. Note that for more complex templates, Smarty "compiles" to PHP:

"Smarty reads the template files and creates PHP scripts from them." http://smarty.php.net/faq.php#3

Can we get back to making a lightweight "skeleton"? In the lightweight department, I think we already want to pick PHP templates, anything else will have more code, no?

Douglas

[arborint]

Can we get back to making a lightweight "skeleton"?

I agree. And I agree that sticking with PHP templates for the minimum makes sense.

In the original post cadmiumgreen shows a switch based Front Controller. He did not deal with the App Controller that would inevitably be in each of his included files.

I am actually interested in people's views on what is the minimum (i.e. skeleton) controller. I would say that an Input/Application Controller is the basic controller. It should be able to work standalone.

Then an optional Front Controller to allow you to centralize some functionality and add mappings that go beyond individual PHP files each containing an Input/Application Controller.

Frameworks like Mojavi, WACT, etc. have controllers crammed full of code to support the specifics of the framework. This makes them not very resuable. So what is the minimum Input/Application Controller and Front Controller? And what other classes are needed: Request, Handle, etc.?

[McGruff]

That is true in some (most?) cases, but now that we have such a thing as the ViewHelper pattern, why not just separate out the presentation logic anyways?

Formatting and data gathering are two different things. You might want to output the same set of data on different pages of a website with different markup, or you might want to output in a range of formats: CLI, pdf, etc.

If you don't apply formatting in a template file, I don't see how you can keep things nicely separated.

Classes which gather the data can roam across the domain or go straight to the data access layer to get what they want, then make this data available to a template file as iterator lists, simple vars or whatever. In templates you need to loop through lists, apply conditionals, and print values. That can be achieved with a custom template language or equally with php itself.

[McGruff]

Can we get back to making a lightweight "skeleton"?

Excuse me - agreed time to move on.

[arborint]

So what do the minimum Application and Front Controllers look like. Let's see some code. Picking up on BerislavLopac's post, index.php would be:

include_once 'AppController.php';
$controller =& new AppController(new Request());
$controller->execute();  // or $controller->run(); ? 

Here is a very basic Request class to kick things off:

class Request {
var $_request = array();
    
function Request() {
    if (!strcasecmp($_SERVER['REQUEST_METHOD'], 'POST')) {
        $this->_request =& $_POST;
    } else {
        $this->_request =& $_GET;
    }
    $this->_request['PATH_INFO'] = $_SERVER['PATH_INFO'];
    if (! get_magic_quotes_gpc()) {
         $this->removeSlashes($this->_request);
    }
}

function removeSlashes(&$str) {
    if (is_array($str)) {
        foreach ($str as $key => $val) {
            if (is_array($val)) {
                $this->removeSlashes($val);
            } else {
                $array[$key] = stripslashes($val);
            }
       }
    } else {
        $str = stripslashes($str);
    }
}

function get($name) {
    return $this->_request[$name];
}
    
function set($name, $value) {
    if ($name) {
        $this->_request[$name] = $value;
    }
}
    
} 

[mwmitchell]

Yep but there is such a thing as layering, and separating those layers. It is surprising and disappointing to realise that there are developers out there, who use OO and design patterns every other day, and still put PHP in HTML.

PHP in your templates has nothing to do with layering and everything to do with personal preference?

- matt

[mwmitchell]

PHP in your templates has nothing to do with layering and everything to do with personal preference?

- matt

Woops, time to move on. Didn't read the whole thread.

[arborint]

Ok, one more time?

Anyone want to show an absolutely minimal Front or Application Controller that would be an OOP and patterns based implementation of the code that cadmiumgreen originally posted? Again, I am assuming that the switch is a Front Controller and that in each of the included PHP files there would be an Application Controller. We also said that templates would be PHP templates for simplicity sake. I threw in a simple Request class.

Or perhaps someone would like to propose the requirements for the minimum Front and Application Controllers so we have an idea of what the target is.

[kyberfabrikken]

Here is a very basic Request class to kick things off:

Surely, if we want a minimal setup, you shouldn't include a Request object ? It's basically just an object-oriented wrapper over an already available feature in php.

[kyberfabrikken]

Making a "minimal" FrontController probably isn't feasible. The method of mapping the request varies greatly, as you can see from some of the posts in theese forums. A solution to that is to use a ChainOfResponsibility with requestmappers, which is flexible but hardly minimal.

I'm not entirely sure that a bare-bones setup should define a framework for the the script which comes after the FrontController. You call it an ApplicationController, but I don't think that's the right term to use ... I never really understood what an ApplicationController is to be honest. I think a more proper word would be Dispatcher, which also implies that the Dispatcher may be simply a ServerPage, or something more complex like a class-based Controller.

Anyway, to join in on the fun, here's a swing at a really lean FrontController ;

class InputController
{
    var $requestMapper=NULL;

    function InputController(&$requestMapper) {
        $this->requestMapper =& $requestMapper;
    }

    function execute() {
        $dispatcher =& $this->requestMapper->mapRequest();
        $dispatcher->execute();
    }
}

/**
   * @abstract
   */
class RequestMapper
{
    /**
       * Maps the request to a proper controller. Use whichever strategy you want.
       * @returns Dispatcher
       */
    function & mapRequest() {
}

class RequestMapper_DefaultMapper extends RequestMapper
{
    function & mapRequest() {
        return new Dispatcher_ServerPage('default.php');
    }
}

/**
   * @abstract
   */
class Dispatcher
{
    function execute() {}
}

class Dispatcher_ServerPage extends Dispatcher
{
    var $fileName;
    function Dispatcher_ServerPage($fileName) {
        $this->fileName = $fileName;
    }
    function execute() {
        include('ServerPages/' . $this->fileName);
    }
} 

index.php

$frontController =& new InputController(new RequestMapper_DefaultMapper());
$frontController->execute(); 

[Dr Livingston]

Here is what I'm working on at the moment, can only put down the Interfaces at the moment, though as I'm still working on it

interface IDispatchController {
public function __construct( IRequestHandler $handler, $mapper );
public function invoke();
}

interface IRequestHandler {
public function __construct( HttpRequest $req, HttpResponse $res );
public function getRequestParameter( $parameter );
public function getLang();
public function getId();
}

interface IComponent {
public function getId();
public function hasChildren();
public function getChildren();
public function attach( IComponent $component );
}

interface IAction {
public function isSecure();
public function setTemplate( $template );
public function getTemplate();
}

interface IHandler {
public function __construct( $controller );
public function setHandler( $handler );
}

interface IActionChain {
public function attach( $handler );
public function process( $request );
}

interface ProcessMapper {
public function compute( IDataSource $ds );
} 

Almost forgot, here is an example which will kick things off

$dispatch = new RequestDispatchController( new Request( new HttpRequest(), new HttpResponse() ), AdjacencyListFactory::create() );
$dispatch -> invoke();
// ... 

At the moment, I'm working on the mapper, which maps the requested action to the required file(s) to be fetched. The mapper eventually could be database based, or XML, or a web service I'm pondering on?

[Dr Livingston]

I think a more proper word would be Dispatcher, which also implies that the Dispatcher may be simply a ServerPage, or something more complex like a class-based Controller.

As you can see, this is the view point that I've taken also Kyber. I also agree with you on the point you've made about the Chain of Responsibility as well. This pattern I believe plays has an important role to fufill.

[Ryan Wray]

Are we answering his question correctly:

I would like to know the general practice that most PHP developers use when designing a website that generally has the same menus, but the content changes.

Most PHP developers don't use design patterns. They often do something along the lines of what he is doing. And, for personal webpages, that actually might just be better than complicated OO applications then quick and dirty webpages with no special, complicated needs.

<?php
require('common.php');

$actions = array(
'news'     => 'file' => 'news/news.php',
'profiles' => 'profiles/profiles.php',
'links'    => 'links/links.php',
'help'     => 'help/help.php',
);

$default_action = 'news';

if (array_key_exists($actions, $_GET['content'])) {
    $title = ucwords($actions[$_GET['content']);
    default_header($title);
    require($actions[$_GET['content']]);
    default_footer();
}
else {
    require($actions[$default_action]);
}
?>

common.php could include functions to make a header and a footer, shared variables and pull in common libraries. Each file could then call what they want. Is it the best design? No. Would I code my website like this? If the site was as simple as this, maybe I would. Hell, SSI sometimes suffices.

He has to weigh his needs. Does his site need to be highly extensible? Is he going to be adding things everywhere, changing functionality continously, etc. Or is the site going to be fairly static, with simple updates only to content.

I fully support good development practices, but sometimes it better to KISS (Keep It Simple Stupid). I might get hearty disagreement, or his site intentions may be much more complicated, but oh well.

[DougBTX]

As you can see, this is the view point that I've taken also Kyber. I also agree with you on the point you've made about the Chain of Responsibility as well. This pattern I believe plays has an important role to fufill.

How would you write this WRT Ryan Wray's comments?

From what you said, I'd assume you've done it before: do you have any code you can share?

Douglas

[Viflux]

I fully support good development practices, but sometimes it better to KISS (Keep It Simple Stupid). I might get hearty disagreement, or his site intentions may be much more complicated, but oh well.

I whole-heartedly agree. The poster posted a question perhaps better suited to the regular PHP forum, and received answers diluted in patterns and unnecessary complications.

I think that, judging by the code in the original post, talk of such patterns is likely more confusing than helpful.

[kyberfabrikken]

@Dr Livingston
I see that you too are suggesting a Request-object. Wouldn't you agree that it's overkill for a bare-bones setup ?
The Response-object is another story. I would likely add that in very early, but I'm not sure if it should be in a minimal setup ?

Are we answering his question correctly

Probably not. This thread went astray many posts back.

Most PHP developers don't use design patterns

If by that you mean, that most php-developers aren't aware that they are following a common design-pattern, you may be right. But the original question was exactly related to which is the common pratice. He may not be using the word "design-pattern", but it's what he meant.

To address the original question ;
What you show us is some markup, with a switch-statement in the middle, that includes other scripts. In academic terms, the script is a hybrid of two components. The php-block with the switch within is called a Controller. The rest of the script (the html-markup) is called the View. It is very common to seperate View and Controller, and is generally consider good practice. That's why I suggested to seperate the two in my first post.

There is another aspect of your code though - I suppose that your "skeleton"-script is the main entry-point for the application. Te scripts main pupose is to dispatch control to another script (you do that by the include-statement). This behaviour is called the FrontController-pattern - It is a very common technique. So in regard to that, the answer to your question would be "yes". The exact implementation could be improved though - using a switch-statement is a bit clumsy.

[kyberfabrikken]

How would you write this WRT Ryan Wray's comments?

It's kind of impossible to implement Chain of Responsibility without using an object-oriented approach. Someone in another thread called CoR an object-oriented switch-statement. I think that really captures the pattern.

Or did I completely miss out on your question ?

[Dr Livingston]

WRT?? Don't know what that abbrev. is for, but to answer your other question I can't share any script.

I wish that I could but that isn't the case at the moment, sorry.

[Dr Livingston]

I would likely add that in very early, but I'm not sure if it should be in a minimal setup ?

Kyber, I would have to differ on this point... You could I suppose get away without using the Response class, but for a basic, minimum setup, a Request class is required. If not, how else could you access $_GET, et al in a standardised fashion through out the application?

I couldn't use $_GET, $_POST, etc directly. Previously I've passed around both the Request and Response objects yes? Not now, I just pass around the Request object, which encapsulates both Request and Response now.

This way, Request and Response remain re-usable, and if I need to add functionality for a specific application, this is done in the Request object. So at the end of the day what I'm saying is that the Request object is disposable.

I think this just increases the re-use of Request and Response, but I wouldn't have that accessability if I excluded them

or something more complex like a class-based Controller.

Your class based controller, the setup would proberly be of a composite based structure. Ideally this is the direction in which you are looking for. I've implemented it (only recently though ), and now Selkirk is looking into it as well for WACT from what I read on a thread the other month there?

[kyberfabrikken]

I couldn't use $_GET, $_POST, etc directly.

Why is that ?
I can only see two reasons for encapsuling them: a) To simplify testing, and b) to allow for other-than-web enviroments (eg. commandline).
If you don't do unittests a) is useless overhead, and let's face it b) is a rarity with php.

[kyberfabrikken]

Your class based controller, the setup would proberly be of a composite based structure. Ideally this is the direction in which you are looking for.

Could you expand on that ? I'm not sure I follow you.

[Dr Livingston]

Sorry, but was you referring to within the context of this thread or in general? If in the context of this thread, and to keep things simple I suppose you could do without a Request object (and a Response object for that matter).

But it's just not something I would do lightly. It's one thing scripting a simple solution for a basic website, but to tear down the bridges you cross on the way, to get there is another.

You may find that the website expands quickly (we wish) in regards to the number of visitors, it's content, etc and the initial solution is no longer upto the task. You need to refactor, quickly and easily.

Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.

[kyberfabrikken]

Sorry, but was you referring to within the context of this thread or in general? If in the context of this thread, and to keep things simple I suppose you could do without a Request object (and a Response object for that matter).

I meant in regards to arborint's challenge to make a minimal FrontController, so that would be in context of this thread.

In a general context I wouldn't go without the Response-object, but I fail to see the real need for a Request-object. I really don't see the harm done in using the superglobals directly.

Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.

It couples your code to the framework.
If you use the superglobals, you could take the code out of your framework and run it elsewhere. That may also be true for the Response-object, but I think it's more appropriate there, since the Response would deal with other things than simply providing a wrapper over existing functionality.

[Dr Livingston]

I see...

It couples your code to the framework.
If you use the superglobals, you could take the code out of your framework and run it elsewhere.

This is an important point I think. But if the said framework, if your developing this yourself, as an ongoing concern (as in my case) then retaining the Request (within framework) is less of an issue, if there is to be greater flexibility from an application devleopment point of view.

Well, that's how I see it anyways, and as I've said earlier you can increase the re-use of both Request and Response easily as I have done... The encapsulating Request object is throwable.

You chuck it away, once you've finished with in, and script another one which is more specific and suitable to your needs. I got this tip from a Java developer, so if they're using this approach, there can't be much wrong with it

[Ryan Wray]

WRT?? Don't know what that abbrev. is for...

I think WRT means With Regards To, but that is only a guess.

If by that you mean, that most php-developers aren't aware that they are following a common design-pattern, you may be right. But the original question was exactly related to which is the common pratice. He may not be using the word "design-pattern", but it's what he meant.

Yes, I was leaning more towards alot php-developers would not be aware they are using design-patterns. It fair to say that, even his original code is a Front Controller.

Just how much trouble (overhead, maintenance) is there in implementing a Request/Response object(s) for a semi-static website? None, but they could prove to be valuable later.

Alot of trouble if he doesn't understand the code he is using. But you do make a good point.

cadmiumgreen: PEAR probably would not help (a CMS would). You're approach should work fine (though, can you echo a require?), but if you're site is going to expand and change alot, you may run into problems. To make things easier, in the beggining, seperate atleast most of you're code from you're presentation. This way, changes in the structure of you webpage (ie. say you decide to change from tables to using generally more accepted methods) will not mean you have to go through multiple PHP pages looking for things to change.

If you're time and needs warrants it, produce high-quality code. It will definetly save you time if in the future you want something more sophisticated. In should also give you reusable libraries, components, etc to use on further projects, which is one of the best benefits (and the most intended benefit of such coding).

Good Luck