Your opinion(s) on flow.

[Geates]

The website I am currently programming is one that has a flow I have not exercised before. Therefore, I'm unsure of it's functional and stable integrity. I am hoping others would share their opinions on execution flow.

The execution flow that I have decided to use seems to be functional and stable but I would not be surprised if it presents some sort of issue as the website evolves. Here is the pseudo-code.

index.php

//define configuration
if new session include "config.php", else session_start()

//execute ALL php processing
include "classes.php"
include "formProcessing.php";

//HTML
include "header.php"
include "navigation.php"
include "control.php"
include "footer.php"

config.php

re/initialize session
define $_SESSION vars
establish mysql connection

classes.php

include "class.a.php"
include "class.b.php"
include "class.c.php"
...

formProcessing.php

if a form was not submitted, return
if not logged in, return
create class objects used in form processing
which form was submitted?  Process the $_POST
update objects that may it (unlikely)
redefine requested page if necessary ($_GET['p'])

header.php, navigation.php, footer.php

create objects used within HTML
HTML code

control.php

what page was requested ($_GET['p'])
switch ($_GET['p'])
  case a : include "a.php"
  case b : include "b.php"
  case c : include "c.php"
  ...

Initially, each php page contained processing code relevant to the page content. However, this led to data inadequacies in the HTML that had already been written. For example, page a.php produces object values that were needed in when the header was processed. Therefore, I changed the flow to execute all processing prior to outputting ANY html.

I hope this conveys my flow well enough. Any comments would be appreciated. Thanks

-Geates

"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[jpadie]

sessions
you don't know whether a session is new or not until you have started the session. so ALWAYS put session_start() on the first line. then test whether a session var is set etc

loading classes
have a look at class autoloading.

controllers
this is the core of MVC and despatch method processing. the call to the process controller would nearly always come above the calls to any output functions. so i would recommend initiating the controller before the nav/header/footer etc.

action switch

switch ($_GET['p'])

no problem with this in specie but you should add extra testing in. i.e.
is the user authorised for that page
is that page callable from the referring page (prevent deep linking)
etc

referencing pages a b c etc
this is probably where we diverge. for one thing, perhaps be a mite more tricky about your naming convention so that people are not tempted to grab pages directly (and of course check for deep linking on each other page.
I do not have separate files for each different action. the vast majority of the heavy lifting is done within the objects I create; and objects are always mapped to entities (in an entity driven application, which most database apps are). instead the switch itself loads the relevant top class and calls a function within the class that does the necessary. the class then hands back to the switch which finally offloads to an output function. this creates a more logical (to me) model-view-controller (hybrid) system.

generally
the despatch method of processing is very scalable, very secure (but still open to coder error leaving vulnerabilities) and has an attractive purity to it.
have a read at PHPSec.Org

 

[Geates]

Thanks, jpadie, for your reply. After reading it and the link you posted, PHPSec.org, I become relieved regarding my implementation. I use a combination of both the dispath method (the only method I've ever used but didn't know it by name before) and the include method.

Although not in the pseudo-code, the formProcessing.php is preceded by security measures. This include re-authenticating the logged in user's username and password, validating a ever changing "token" passed in the $_POST, and white-listing $_POST data into private class vars where they are then used in processing (ALL class vars are private, only class functions are public).

As for the control.php include, perhaps it is misnamed. It simply determines which HTML code to output (via include) and is not responsible for ANY php processing. All php processing is done in the formProcessing.php before anything is sent to the document header.

What do you mean by deep-linking?

-Geates



"I hope I can chill and see the change - stop the bleed inside and feel again. Cut the chain of lies you've been feeding my veins; I've got nothing to say to you!"
-Infected Mushroom

"I do not offer answers, only considerations."
- Geates's Disclaimer

 

[jpadie]

What do you mean by deep-linking?

pretty much the same as wikipedia save that i am more concerned with stopping deep linking only when you don't want it.

the way I do this is as follows

1. have a definition that is only ever loaded on index.php
2. on other pages that you do not want deep linked, add this code

if (!is_defined('MY_DEFINITION')) die ('-1'); //from wordpress

alternatively you could redirect.

header('Location: index.php');

you can also do the same thing using apache redirects.

RewriteEngine on
RewriteCond !^.\/index.php.*$ [NC]
RewriteRule .*\.(html|htm|php)$ - [F]

the above will force a forbidden response. easily changed to redirect to index.php instead. it will allow deep-linking to assets though (e.g. images etc). for secure applications it is best to stop all deep linking and to redirect asset requests through a serverscript that tests for authentication and authorisation before serving the file to the browser.