Application design – PHP

  php

Q(Question):

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php
…..

Do you write one long script, and then call parts of it using a variable?

example:

contact.php?action=add

Or do you do something else, like use a MVC design pattern? I’m interested
in rethinking the way I write stuff. Any suggestions would be helpful.

Thanks

A(Answer):

In article <NZ*****************@twister.tampabay.rr.com>,
"Jason" <js******@cfl.rr.com> wrote:

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php

I prefer to do it like that, including shared code at the top of each
section, like this:

include(‘contact_defs.inc.php’);
include(‘contact_functions.inc.php’);
Do you write one long script, and then call parts of it using a variable?

example:

contact.php?action=add

I’d rather not do it like that. The ‘one long script’ has a tendency to
become spaghetti code with way too many ‘if … elseif ….’ sections in
it pretty quick.

Also, to keep my scripts clean, concise and ‘to the point’, I usually
offload all HTML production to Smarty. (see http://smarty.php.net/).

JP


Sorry, <de*****@cauce.org> is een "spam trap".
E-mail adres is <jpk"at"akamail.com>, waarbij "at" = @.

A(Answer):

On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <js******@cfl.rr.com> scrawled:

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php
….

Many draw backs to this – mainly with duplicating large amounts of user
code (security at the top) of each script, and having to jump through
hoops to correctly handle "fall-back" scenarios.
Do you write one long script, and then call parts of it using a variable?

example:

contact.php?action=add

I tend to do it this way… but create an action class…

with methods such as ACTION_add, ACTION_delete, ACTION_edit…

The I have code which collections the action from the URL, checks to see
if the ACTION_{$action} method exists – and if so calls it…

This method has many advantages over the single script… you end up not
duplicating many of the "fall-back" actions many times…

It is much easier to add user level security at this sort of level.. (in
fact it becomes easy to set up configurable security levels)

AND you don’t end up with the "spaghetti" code

My "class" heirachy often ends up as:

"application".inc
|
| (isa)
|
core.inc (central functions
|
| (isa)
|
site.inc (general templating code)
|
| (hasa)
|
dbhandle.inc (database interface code – like perl’s DBI)Or do you do something else, like use a MVC design pattern? I’m interested
in rethinking the way I write stuff. Any suggestions would be helpful.

A(Answer):

Very useful! Thanks

"James" <ne*******@black-panther.freeserve.co.uk> wrote in message
news:3f***************@news.freeserve.com…

On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <js******@cfl.rr.com> scrawled:

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php
….

Many draw backs to this – mainly with duplicating large amounts of user
code (security at the top) of each script, and having to jump through
hoops to correctly handle "fall-back" scenarios.

Do you write one long script, and then call parts of it using a variable?

example:

contact.php?action=add

I tend to do it this way… but create an action class…

with methods such as ACTION_add, ACTION_delete, ACTION_edit…

The I have code which collections the action from the URL, checks to see
if the ACTION_{$action} method exists – and if so calls it…

This method has many advantages over the single script… you end up not
duplicating many of the "fall-back" actions many times…

It is much easier to add user level security at this sort of level.. (in
fact it becomes easy to set up configurable security levels)

AND you don’t end up with the "spaghetti" code

My "class" heirachy often ends up as:

"application".inc
|
| (isa)
|
core.inc (central functions
|
| (isa)
|
site.inc (general templating code)
|
| (hasa)
|
dbhandle.inc (database interface code – like perl’s DBI)

Or do you do something else, like use a MVC design pattern? I’m
interestedin rethinking the way I write stuff. Any suggestions would be helpful.

A(Answer):

"Jan Pieter Kunst" <de*****@cauce.org> wrote in message
news:de***************************@news1.news.xs4a ll.nl…

In article <NZ*****************@twister.tampabay.rr.com>,
"Jason" <js******@cfl.rr.com> wrote:

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php

I prefer to do it like that, including shared code at the top of each
section, like this:

include(‘contact_defs.inc.php’);
include(‘contact_functions.inc.php’);

Do you write one long script, and then call parts of it using a
variable?
example:

contact.php?action=add

I’d rather not do it like that. The ‘one long script’ has a tendency to
become spaghetti code with way too many ‘if … elseif ….’ sections in
it pretty quick.

Also, to keep my scripts clean, concise and ‘to the point’, I usually
offload all HTML production to Smarty. (see http://smarty.php.net/).

JP


Sorry, <de*****@cauce.org> is een "spam trap".
E-mail adres is <jpk"at"akamail.com>, waarbij "at" = @.

I break mine up too….but I use patTemplate instead of Smarty 🙂

A(Answer):

"Jason" <js******@cfl.rr.com> wrote in message
news:NZ*****************@twister.tampabay.rr.com.. .

How do most of you construct your applications?
Or do you do something else, like use a MVC design pattern? I’m interested
in rethinking the way I write stuff. Any suggestions would be helpful.

here is one possible approach with combination of templates and MVC

http://www.templatetamer.org/index.p…trollerPattern

rush

http://www.templatetamer.com/

A(Answer):

"Jason" <js******@cfl.rr.com> wrote in message news:<NZ*****************@twister.tampabay.rr.com> …

How do most of you construct your applications?

Do you break it up into sections based on the functions of the app?

example:

contact_add.php
contact_delete.php
contact_edit.php
….

Do you write one long script, and then call parts of it using a variable?

example:

contact.php?action=add

Or do you do something else, like use a MVC design pattern? I’m interested
in rethinking the way I write stuff. Any suggestions would be helpful.

Thanks

I have very small scripts that perform a single function each, as in
your first example, as I find smaller scripts a lot easier to
maintain. I also use the 3 tier architecture which means that all my
business logic for each entity is maintained in a single class which
can then be shared by any number of scripts in the presentation layer.

All my HTML is generated from XML data files which are then
transformed using XSL stylesheets. I have found that I can place a lot
of my XSL code in small files which I can reuse by using the
<xsl:include> command.

For an overview of my environment check out
http://www.tonymarston.net/php-mysql…structure.html

Tony Marston
http:/www.tonymarston.net/

LEAVE A COMMENT