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

[Jan Pieter Kunst]

In article <NZW8b.18342$kX.1326@twister.tampabay.rr.com>,
"Jason" <jsumner1@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 [url]http://smarty.php.net/[/url]).

JP

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

[James]

On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <jsumner1@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.

[Jason]

Very useful! Thanks

"James" <newsgroup@black-panther.freeserve.co.uk> wrote in message
news:3f645344.67911992@news.freeserve.com...

> On Sun, 14 Sep 2003 09:59:09 GMT, "Jason" <jsumner1@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.

>
>
>

[Jason]

"Jan Pieter Kunst" <devnull@cauce.org> wrote in message
news:devnull-95418B.12534414092003@news1.news.xs4all.nl...

> In article <NZW8b.18342$kX.1326@twister.tampabay.rr.com>,
> "Jason" <jsumner1@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 [url]http://smarty.php.net/[/url]).
>
> JP
>
> --
> Sorry, <devnull@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 :)

[rush]

"Jason" <jsumner1@cfl.rr.com> wrote in message
news:NZW8b.18342$kX.1326@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

[url]http://www.templatetamer.org/index.php?ModelViewControllerPattern[/url]

rush
--
[url]http://www.templatetamer.com/[/url]

[Tony Marston]

"Jason" <jsumner1@cfl.rr.com> wrote in message news:<NZW8b.18342$kX.1326@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
[url]http://www.tonymarston.net/php-mysql/infrastructure.html[/url]

Tony Marston
http:/www.tonymarston.net/

[DuLaus]

Hi I will be passing around an #id# (lodging) between a local database query
and a web service. Descriptive data resides in a database with the #id#, then
additional data is then requested using a webservice with the same #id# as in
the database. It is always a db query first, then webservice second. There are
100,000 records, and the web clients will not be members or have any ID of
their own while browsing and changing the #id# if they wish to do so. Question
is do I created a #session.id# per client query, and do I use cookies to keep
the user requests in sync with that #id# as many clients may be using the
website at the same time. Thanks

[DuLaus]

bump