Designing server-side applications in PHP

Try out both, see which one you prefer. No warranties.

That kind of response, though appreciated, is one that could be said for anything that involves multiple possibilities. I was rather looking for opinions from an engineering perspective. Any engineers out there that have done some studies on web design techniques? I know you're out there.

This is a matter of personal taste, not web design.

looks like i know what i am saying, but not explaining it right. there has to be a science with pros and cons of laying out sites in different forms. i just wanted to hear what others have experienced in laying out their sites in different ways, what obstacles they faced. it sounds silly, but this is an obstacle for me.

Nope, not much science, just art and opinion. Here's some opinions:

• make the urls readable and rememberable and reusable - people like to bookmark urls, give them to friends, write them down, use them to tell where they are etc .. so huge long query string are ugly
• i like to keep as much related functionality together in one page as i can, but user's often see things differently. theirs is the opinion that counts.
• ice cream has no bones

I would also say - Try to keey URL readable and nice.
That means it must have no substring ".php" in it. It also must be free of "?vat=bat" if it is not search query.

So you need to have http://host/part/ for parts of site and http://host/part/page.html for pages. It is irrelevant how you could do it.

Possible solutions:

• Just place one script and pooint ErrorDocument 404 to it
• Place in every dir "index.php", but it will not solve "page.html" part.
• Make .html files to be parced by PHP (it is not good solution for most cases, but it is solution).
• Make dafault type "x-.../php" instead of "text/plain" and create script with name part and put it to root. Then http://host/part/page.html will call this script "part" with parameter "/page.html", and
  http://host/part/dir2/page.html - with "/dir2/page.html".
• Use mod_rewrite to rewrite http://host/part/dir2/page.html into http://host/part.php?a=dir2&b=page.html (internally)

Note - Mozilla gestures have one, with is substract last component of URL. So you _must_ have http://host/part/ filled if you have some http://host/part/page.html

wow, that some really neat stuff, i'm gonna' give it a go. what are the pros and cons of having the browser read FOO.php and FOO.html that was parsed by FOO.php ?

Something that might be more useful:

Have your main script parse the value of $GLOBALS['PATH_INFO'] to see what "section" of your app to execute. For instance:

$commands['/read'] = 'show_read';
$commands['/write'] = 'show_write';
$commands[''] = 'show_default';

 if ($commands[$GLOBALS['PATH_INFO']]) {
  $commands[$GLOBALS['PATH_INFO']]();
}
else {
  die "Invalid Command";
}

Then, your app can call whatever.php/read to run the show_read(), whatever.php/write to execute the show_write() function, etc. You can also parse the PATH_INFO in any other ways you might invent in order to discover variables, etc.

On a somewhat unrelated note, it's often convenient for apps that will be used by new users to have POST operations post to a page that does the required operations (say, insert data into a database) and then redirect (using Header("Location: foo")) to the result page. This keeps them from re-executing the same code when they foolishly hit the back button.

You should be aware that redirecting from a POST to a GET is not actually supposed to work (unless PHP is doing particular magic). RFC 2068 said

   If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

      Note: When automatically redirecting a POST request after receiving
     a 302 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.

By the time they got to RFC 2616, they apparently realised that "some existing HTTP/1.0" user agents includes basically every useful browser out there, so they changed the wording to "most existing user agent[s]" and introduced new responses 303 (allow redirect from POST, always using GET) and 307 (don't redirect from POST, just like they originally intended 302 to have done). So you probably should be using a 303 instead of a 302 for this purpose. If your users know what it is. How do you test that? I've no idea: it seems unlikely that simply checking the HTTP request version for 1.1ness is going to be particularly accurate. Frankly I'd be a lot happier if they'd just repurposed 302 instead of creating 303, but we have to hope there was some good reason for not following existing practice there.

PATH_INFO
I was telling about this as a possible solution. just a note - do not forget to correct relative image pathes. If you have URL page.php/smth , then all images should be prepended with "../" if page.php/smth/second - then "../../". Browser is not capable of distinguish this from directory

And again - if you would "mv page.php page" and make default MIME type to ...php you will get page/smth/second, instead of page.php/smth/second.

About .php and .html
The only bad difference is that 1) you need correctly otput Page-Last-Modified, 2) it will not work well on havy loads - you should use more static html-s.
The good thing is 1) when user saves page it will get correct file extension , 2) URL looks good :)

As concerning the multiple step part of your question.. Use sessions and cut down the reliance on the browser. There are built-in sessions with PHP and my Javuh project has an object-oriented version. It's on my mind because of a simple HowTo I just wrote today on the matter.

-- Page 1 --
<?
   $sess->set( "my_form_data", array( $field_1, $field_2 ) );
?>

-- Page 2 --
<?
   $sess->( "my_form_data", array_push(
       $sess->get( "my_form_data" ),
       array( $field_3, $field_4 ) ) );
?>

-- Page 3 --
<?
   $sess->( "my_form_data", array_push(
       $sess->get( "my_form_data" ),
       array( $field_5, $field_6 ) ) );
?>

-- and so on until.. --
<?
   $all_data = $sess->get( "my_form_data" );
   // use $all_data[0], [1], .. [5]
?>

Session data is nicer because you can pass around native PHP objects rather than just strings. You don't have to rebuild your data structures every time the page loads. Another nice feature of Javuh sessions are "session actions." You register an action in the session and the class uses a hash to verify it's legitimacy on submission. Basically, this keeps page refreshes from resubmitting and enhances security. I've also recently had problems with Mozilla reloading a page ten times if one of my pages returns no data while in development. Session actions helped me keep the refresh to once.

Anyway, good luck. The single script for ErrorDocument is a fun little trick, ain't it?

thank you 'whytheluckystiff' :) that is the kind of article that i love to read, well written, concise, informative, a lead to other articles like it. what else can i say? :) i went to your site, some cool stuff going on over there.

i know this is sort of off topic. But in my shop, one application which uses Crystal Report used to require user to use only Microsfot IE but not Netscape or any other kind. Limiting developer or end-user choices is one thing that i don't like. Now the new Crystal Enterprise 8.0 will accomadate both ASP (Active Server Page) and CSP (Crystal Server Page) for the server-side scripting environment. I am curious to know about pros and cons for the two methods from both developer and end user point of view. Personally, i don't really get involved with any of those development.

I have been working on a PHP application framework
similar in scope, not in scale by any means, to Zope (http://zope.org).

I call it a PHPortal (http://dev.4arrow.com).

It uses a similar UI to the management panels of Zope and a somewhat similar way of working with reusable http URI Objects as a easy way to build and maintian a large number of web sites and applications in a secure acl user group environement.

One of my goals in creating PHPortal was to not require any special root server access or additonal modules besides the standard PHP Apache setup so it can be used in most shared web hosting accounts.

Some features include:

1. over 20 content-type transformations (html,xhtml,css,javascript,rss,opml,xml,text to speech,text,wml,xml- rpc,xsl,xls,word,rtf,pdf,source,png,swf,vxml,zip,gzip)
2. unlimited websites under one object umbrella (literally one file is used for the gateway handler for all URI Requests)
3. no manual file CHMODing with no need to leave files or directories writable
4. Cut, copy, paste, import and export objects
5. versioning, history, undos,
6. built in XMLRPC server that 'listens,'
7. URI based virtual file folder sytem
8. ACL user group access
9. advanced security options per object using local access roles
10. built in logging, log archiving, sessions
11. cross-domain cookies
12. built in search
13. large pool of resuable drop and run applications (not public quite yet)

You may find these references useful:

REST and the Real World, by Paul Prescod

RESTwiki

Sun's J2EE Design Patterns > Model-View-Controller Architecture (MVC is OO-talk, not just Java)