Application design

[Jason]

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.ph p
.....

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

example:

contact.php?act ion=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

[Jan Pieter Kunst]

Re: Application design

In article <NZW8b.18342$kX .1326@twister.t ampabay.rr.com> ,
"Jason" <jsumner1@cfl.r r.com> wrote:
[color=blue]
> 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.ph p[/color]

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

include('contac t_defs.inc.php' );
include('contac t_functions.inc .php');
[color=blue]
> Do you write one long script, and then call parts of it using a variable?
>
> example:
>
> contact.php?act ion=add[/color]

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, <devnull@cauce. org> is een "spam trap".
E-mail adres is <jpk"at"akamail .com>, waarbij "at" = @.

[James]

Re: Application design

On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <jsumner1@cfl.r r.com> scrawled:
[color=blue]
>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.ph p
>contact_delete .php
>contact_edit.p hp
>....
>[/color]

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.
[color=blue]
>Do you write one long script, and then call parts of it using a variable?
>
>example:
>
>contact.php?ac tion=add[/color]

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".i nc
|
| (isa)
|
core.inc (central functions
|
| (isa)
|
site.inc (general templating code)
|
| (hasa)
|
dbhandle.inc (database interface code - like perl's DBI)[color=blue]
>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.[/color]

[Jason]

Re: Application design

Very useful! Thanks

"James" <newsgroup@blac k-panther.freeser ve.co.uk> wrote in message
news:3f645344.6 7911992@news.fr eeserve.com...[color=blue]
> On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <jsumner1@cfl.r r.com> scrawled:
>[color=green]
> >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.ph p
> >contact_delete .php
> >contact_edit.p hp
> >....
> >[/color]
>
> 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.
>[color=green]
> >Do you write one long script, and then call parts of it using a variable?
> >
> >example:
> >
> >contact.php?ac tion=add[/color]
>
> 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".i nc
> |
> | (isa)
> |
> core.inc (central functions
> |
> | (isa)
> |
> site.inc (general templating code)
> |
> | (hasa)
> |
> dbhandle.inc (database interface code - like perl's DBI)[color=green]
> >Or do you do something else, like use a MVC design pattern? I'm[/color][/color]
interested[color=blue][color=green]
> >in rethinking the way I write stuff. Any suggestions would be helpful.[/color]
>
>
>[/color]

[Jason]

Re: Application design

"Jan Pieter Kunst" <devnull@cauce. org> wrote in message
news:devnull-95418B.12534414 092003@news1.ne ws.xs4all.nl...[color=blue]
> In article <NZW8b.18342$kX .1326@twister.t ampabay.rr.com> ,
> "Jason" <jsumner1@cfl.r r.com> wrote:
>[color=green]
> > 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.ph p[/color]
>
> I prefer to do it like that, including shared code at the top of each
> section, like this:
>
> include('contac t_defs.inc.php' );
> include('contac t_functions.inc .php');
>[color=green]
> > Do you write one long script, and then call parts of it using a[/color][/color]
variable?[color=blue][color=green]
> >
> > example:
> >
> > contact.php?act ion=add[/color]
>
> 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, <devnull@cauce. org> is een "spam trap".
> E-mail adres is <jpk"at"akamail .com>, waarbij "at" = @.
>[/color]

I break mine up too....but I use patTemplate instead of Smarty :)

[rush]

Re: Application design

"Jason" <jsumner1@cfl.r r.com> wrote in message
news:NZW8b.1834 2$kX.1326@twist er.tampabay.rr. com...[color=blue]
> How do most of you construct your applications?[/color]
[color=blue]
> 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.[/color]

here is one possible approach with combination of templates and MVC

http://www.templatetamer.org/index.php?ModelViewControllerPattern

rush
--

http://www.templatetamer.com/

[Tony Marston]

Re: Application design

"Jason" <jsumner1@cfl.r r.com> wrote in message news:<NZW8b.183 42$kX.1326@twis ter.tampabay.rr .com>...[color=blue]
> 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.ph p
> ....
>
> Do you write one long script, and then call parts of it using a variable?
>
> example:
>
> contact.php?act ion=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[/color]

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/infrastructure.html

Tony Marston
http:/www.tonymarston .net/