PHP site development

[Me]

I would like to redesign my existing site into php using classes.
I am not the most experienced developer with PHP, and would like to know
if anyone can give me some input on a starting point for a class library.
Basically, the idea is to have as much of the content served dynamically,
using a mySQL database. My catalog site has grown to over 1,100 pages,
and is continuing to grow. It's getting ridiculous to keep performing
manual updates.

Thanks for any input. I appreciate the feedback.

[Tony Marston]

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
which identifies a development environment based on the 3 tier architecture.

Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can
run online. You can also download all the source code and see how it ticks.
This uses classes for all entity and database access, so it should give you
an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

--
Tony Marston

http://www.tonymarston.net

"Me" <jd******@atlantic.net> wrote in message
news:pa***************************@atlantic.net...

I would like to redesign my existing site into php using classes.
I am not the most experienced developer with PHP, and would like to know
if anyone can give me some input on a starting point for a class library.
Basically, the idea is to have as much of the content served dynamically,
using a mySQL database. My catalog site has grown to over 1,100 pages,
and is continuing to grow. It's getting ridiculous to keep performing
manual updates.

Thanks for any input. I appreciate the feedback.

[Me]

Tony~
Having spent lots of time in the database world, I must say that I relate
yo some of your history very well. I have spent the last 6 hours or so
reading through different articles and tutorials which you have authored
on your site, and I am happy to say that I am learning as much as I ever
have in a longer period of time than I care to remember. While PHP
doesn't seem strange to me (especially in the context you put it in
combining object oriented approaches to data manipulation), some of how
it is implemented appears a little 'fuzzy'. But, I have a feeling that
by the time I complete reading the rest of the referenced parts
mentioned on your site, I may well have enough information to poke
through the fog and formulate some ideas on how to properly design an
implementable application for web use. Thank you very much for creating
this site. I consider it a valuable resource on the subject. I hope
that you will remain in the 'universe' for further inquiries by those of
us who appreciate what you have endeavored to teach.

Kind regards...

On Mon, 05 Jul 2004
22:10:39 +0100, Tony Marston wrote:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
which identifies a development environment based on the 3 tier architecture.

Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can
run online. You can also download all the source code and see how it ticks.
This uses classes for all entity and database access, so it should give you
an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

[Tony Marston]

"Me" <jd******@atlantic.net> wrote in message
news:pa****************************@atlantic.net.. .

Tony~
Having spent lots of time in the database world, I must say that I relate
yo some of your history very well. I have spent the last 6 hours or so
reading through different articles and tutorials which you have authored
on your site, and I am happy to say that I am learning as much as I ever
have in a longer period of time than I care to remember. While PHP
doesn't seem strange to me (especially in the context you put it in
combining object oriented approaches to data manipulation), some of how
it is implemented appears a little 'fuzzy'.
New and different implementations always appear fuzzy at first, but as you
become more familiar with them the fog begins to clear.
But, I have a feeling that
by the time I complete reading the rest of the referenced parts
mentioned on your site, I may well have enough information to poke
through the fog and formulate some ideas on how to properly design an
implementable application for web use. Thank you very much for creating
this site. I consider it a valuable resource on the subject. I hope
that you will remain in the 'universe' for further inquiries by those of
us who appreciate what you have endeavored to teach.

Kind regards...
Thank you for those kind words. It is nice to know that my humble efforts
are appreciated.

--
Tony Marston

http://www.tonymarston.net
On Mon, 05 Jul 2004
22:10:39 +0100, Tony Marston wrote:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html which identifies a development environment based on the 3 tier architecture.
Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can run online. You can also download all the source code and see how it ticks. This uses classes for all entity and database access, so it should give you an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

[atlantic]

Tony~
I'm really enjoying going through this material. I can already see a number
of application implementations for this architecture. Would you consider
this architecture to be 'overkill' for the basic functionality of a catalog
type website? The current site I've inherited has alot of pages (over
1,000) , and really needs this kind of organization, but I have yet to see
anyone produce even the most simplistic sample of one which can be built on.
To date, the site I have inherited is strictly view, with the exception
that, an on-line order form has been added (which needs complete revamping
btw) was added. While I have a 'grand design' in mind for more user
interaction (logins, tracking, etc), I'd like to start with the users view
and work front to back. While I know that, strictly speaking, that backend
is historically the place I've always begun my work, I'd like to try and get
a feel for the front-end design using your architecture. If you have a
moment and would like to see what I am talking about, the site is located at
www.genofit.com . I look forward to, and greatly respect your feedback.

Thank you again for your help. I seem to be learning more from your web
site each time I read through it...

Regards
"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message
news:cc*******************@news.demon.co.uk...

"Me" <jd******@atlantic.net> wrote in message
news:pa****************************@atlantic.net.. .

Tony~
Having spent lots of time in the database world, I must say that I relate

yo some of your history very well. I have spent the last 6 hours or so
reading through different articles and tutorials which you have authored
on your site, and I am happy to say that I am learning as much as I ever
have in a longer period of time than I care to remember. While PHP
doesn't seem strange to me (especially in the context you put it in
combining object oriented approaches to data manipulation), some of how
it is implemented appears a little 'fuzzy'.
New and different implementations always appear fuzzy at first, but as you
become more familiar with them the fog begins to clear.

But, I have a feeling that
by the time I complete reading the rest of the referenced parts
mentioned on your site, I may well have enough information to poke
through the fog and formulate some ideas on how to properly design an
implementable application for web use. Thank you very much for creating
this site. I consider it a valuable resource on the subject. I hope
that you will remain in the 'universe' for further inquiries by those of
us who appreciate what you have endeavored to teach.

Kind regards...

Thank you for those kind words. It is nice to know that my humble efforts
are appreciated.

--
Tony Marston

http://www.tonymarston.net

On Mon, 05 Jul 2004
22:10:39 +0100, Tony Marston wrote:

Take a look at

http://www.tonymarston.co.uk/php-mys...structure.html which identifies a development environment based on the 3 tier architecture.
Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which shows how it also incorporates the Model-View-Controller design pattern.
There is a sample application based on these architectures described in http://www.tonymarston.net/php-mysql...plication.html which you can run online. You can also download all the source code and see how it ticks. This uses classes for all entity and database access, so it should

give you an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

[Henk Verhoeven]

Hi Tony,

Interesting site. MVC, 3 tier, yes, of course! But XSLT may as yet be
more of a personal preference of yours. For most php developers, php's
own hypertext preprocessing might be easier. And it CAN be used with
presentation logic objects, see
http://www.phppeanuts.org/site/index...principle.html
and example 5:
http://www.phppeanuts.org/site/index...stom+skin.html

Greetings,

Henk Verhoeven,
www.phpPeanuts.org
Tony Marston wrote:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
which identifies a development environment based on the 3 tier architecture.

Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can
run online. You can also download all the source code and see how it ticks.
This uses classes for all entity and database access, so it should give you
an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

[Tony Marston]

"atlantic" <[e-mail]> wrote in message
news:w9****************@monger.newsread.com...

Tony~
I'm really enjoying going through this material. I can already see a number of application implementations for this architecture. Would you consider
this architecture to be 'overkill' for the basic functionality of a catalog type website?
You do not use different architectures for different sizes of application. A
small application may grow into a large application over time, and you don't
want to switch architectures in mid stream.

In order to provide the benefits of a RAD (Rapid Application Development)
environment what you need is a series of components that provide standard
functionality in a reusable form. If you look at Figure 5 in
http://www.tonymarston.co.uk/php-mys...e.html#figure5 you will
see what looks like a very complicated architecture, but the following parts
have already been written and are waiting to be used:
- the abstract table class
- the validation class
- the DML class
- dialog type scripts
- generic XSL files
- a default CSS file

To build a component all you have to do is the following:-
- For each database table construct a subclass which extends the abstract
table class. As a bare minimum this simply describes the structure of that
database table.
- Construct a component script (see
http://www.tonymarston.co.uk/php-mys...mponent-script)
which identifies three things:
a) Which business entity (database table) to use - this is the Model part of
MVC.
b) Which screen structure script to use - this is the View part of MVC.
c) Which dialog type script to use - this is the controller part of MVC.

You should be able to recognise that the complicated part has already been
done so that the construction of new components is made as simple as
possible.
The current site I've inherited has a lot of pages (over
1,000) , and really needs this kind of organization, but I have yet to see
anyone produce even the most simplistic sample of one which can be built on. To date, the site I have inherited is strictly view, with the exception
that, an on-line order form has been added (which needs complete revamping
btw) was added. While I have a 'grand design' in mind for more user
interaction (logins, tracking, etc), I'd like to start with the users view
and work front to back. While I know that, strictly speaking, that backend
is historically the place I've always begun my work, I'd like to try and get a feel for the front-end design using your architecture.
There are two parts to every website - the front-end (which is accessed by
the general public) and the back-end (which is accessed by the site
administrator). The back-end maintains the database which is used by the
front-end. This may appear simple at first but has a habit of growing. For
example, you may have a large database which several people can access for
maintenance purposes but you decide that not all that these people should be
able to update every part of the database. That's where an access control
system is needed. You may then decide that you need an audit trail to keep
track of who changed what and when. That's when you need an audit trail
system. You may then decide that you need a workflow system so that one
action can automatically trigger one or more other actions.

You may be interested to know that I have already extended my software to
include a Role Based Access Control (RBAC) system, an Audit Trail system and
a Workflow system, so that proves how extensible it is.
If you have a
moment and would like to see what I am talking about, the site is located at www.genofit.com . I look forward to, and greatly respect your feedback.
The colours are a bit dark and gloomy, and I personally do not like the use
of client-side scripting (especially ActiveX controls) which is why I have
those options turned off. Consequently parts of your website did not display
as you intended.
Thank you again for your help. I seem to be learning more from your web
site each time I read through it...

It is nice to know that my humble efforts are appreciated.

--
Tony Marston

http://www.tonymarston.net

[Tony Marston]

"Henk Verhoeven" <ne**@phppeanutsREMOVE-THIS.org> wrote in message
news:cc**********@news3.tilbu1.nb.home.nl...

Hi Tony,

Interesting site. MVC, 3 tier, yes, of course! But XSLT may as yet be
more of a personal preference of yours. For most php developers, php's
own hypertext preprocessing might be easier.
I know that PHP was designed to output HTML directly, but past experience
with other languages has taught me the benefit of separating presentation
logic from business logic. This meant that I needed to use some sort of
templating system to deal with all HTML output. As I was already familiar
with XML and XSL, and because PHP already had the capabilities to deal with
them both, I decided to go with this approach. The problem with a templating
system like Smarty is that it is tied to PHP whereas XML and XSL exist as
international standards which are maintained by the World Wide Web
Consortium (W3C) and are consequently available to a much wider audience. My
experience with XSL has allowed me to create generic stylesheets with an
amazing amout of reusability, so as far as I am concerned it is was a good
choice.

Other people may be happy with other solutions, but that is their choice.
And it CAN be used with
presentation logic objects, see
http://www.phppeanuts.org/site/index...principle.html
and example 5:
http://www.phppeanuts.org/site/index...stom+skin.html
I don't think I shall abandon my own approach just yet.

--
Tony Marston

http://www.tonymarston.net
Greetings,

Henk Verhoeven,
www.phpPeanuts.org
Tony Marston wrote:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html which identifies a development environment based on the 3 tier architecture.
Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can run online. You can also download all the source code and see how it ticks. This uses classes for all entity and database access, so it should give you an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

[Gary L. Burnore]

On Wed, 7 Jul 2004 11:45:33 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> wrote:

"atlantic" <[e-mail]> wrote in message
news:w9****************@monger.newsread.com...

Tony~
I'm really enjoying going through this material. I can already see anumber

of application implementations for this architecture. Would you consider
this architecture to be 'overkill' for the basic functionality of a

catalog

type website?

You do not use different architectures for different sizes of application.

You might not. Many do.
A small application may grow into a large application over time, and you don't
want to switch architectures in mid stream.
Yeah and pigs may fly so you should always carry an umbrella. Some
systems, by design, are small and will remain small and require a
different architecture.
[snip very good stuff that's not applicible to every situation]

There are two parts to every website - the front-end (which is accessed by
the general public) and the back-end (which is accessed by the site
administrator).

Perhaps you meant 'you can devide a website into two parts if you want
to'?

Overkill, when not required, costs more money, wastes time on the
upstart and causes headaches later. It's not _ALWAYS_ a good thing to
over do it at the start.
--
gburnore@databasix dot com
---------------------------------------------------------------------------
How you look depends on where you go.
---------------------------------------------------------------------------
Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
| ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
DataBasix | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³
| ÝÛ³ 3 4 1 4 2 ݳ޳ 6 9 0 6 9 ÝÛ³
Black Helicopter Repair Svcs Division | Official Proof of Purchase
================================================== =========================
Want one? GET one! http://www.databasix.com
================================================== =========================

[Tony Marston]

"Gary L. Burnore" <gb******@databasix.com> wrote in message
news:cc**********@blackhelicopter.databasix.com...

On Wed, 7 Jul 2004 11:45:33 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> wrote:

"atlantic" <[e-mail]> wrote in message
news:w9****************@monger.newsread.com...

Tony~
I'm really enjoying going through this material. I can already see anumber

of application implementations for this architecture. Would you consider this architecture to be 'overkill' for the basic functionality of a

catalog

type website?

You do not use different architectures for different sizes of application.
You might not. Many do.
Then that is their choice. IMHO it is a poor choice.
A small application may grow into a large application over time, and you don'twant to switch architectures in mid stream.

Yeah and pigs may fly so you should always carry an umbrella. Some
systems, by design, are small and will remain small and require a
different architecture.

I have seen a lot of systems which start small yet grow and grow over time.
A single architecture which can handle both small and large systems would be
more useful than separate architectures that can only handle one or the
other. If you write a small system which cannot be extended as new
requirements materialise I am sure that your customers will be greatly
impressed - NOT!
[snip very good stuff that's not applicible to every situation]

There are two parts to every website - the front-end (which is accessed bythe general public) and the back-end (which is accessed by the site
administrator).
Perhaps you meant 'you can devide a website into two parts if you want
to'?

Having spent some time working in a team which maintained the back-end
transactions while another team dealt with the front-end I am not the only
one who considers the front and back ends to be separate entities. The only
common ground between them is the database in the middle.
Overkill, when not required, costs more money, wastes time on the
upstart and causes headaches later. It's not _ALWAYS_ a good thing to
over do it at the start.

It depends on your definition of "over doing". Experience has taught me that
there are two ways of doing a job - properly or not at all. Doing a "proper
job" means having an architecture that will deal with any size of web
application, small or large.

--
Tony Marston

http://www.tonymarston.net

[Larry Jaques]

On Wed, 7 Jul 2004 14:34:50 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> calmly ranted:

"Gary L. Burnore" <gb******@databasix.com> wrote in message

Overkill, when not required, costs more money, wastes time on the
upstart and causes headaches later. It's not _ALWAYS_ a good thing to
over do it at the start.

It depends on your definition of "over doing". Experience has taught me that
there are two ways of doing a job - properly or not at all. Doing a "proper
job" means having an architecture that will deal with any size of web
application, small or large.

Remember, Tony, that not all of us get the large clients who
give -us- full say in how much the site costs. For the rest of
us, we quote prices for specific goodies, often giving them
one quote for the basics (which 75% of them want) and one quote
for a website with everything on it (including anchovies, which
few want.)

Most sole proprietors and mom & pop shops can't afford all the
bells and whistles at one time, so we offer less complete/less
costly sites to get them started. How can that be "wrong" if we
tell them that the original site programing may have to be scrapped
once they get to a certain performance/demand level, and another
more robust model set in its place? I'm with Gary on this point
because using your model alone, about 80% of all sites would not
be online today. (Hmmm, in some ways that might not be such a bad
thing after all.) ;>
----------------------------------------------
Never attempt to traverse a chasm in two leaps
http://www.diversify.com Comprehensive Website Design
================================================== =========

[Tony Marston]

"Larry Jaques" <novalidaddress@di\/ersify.com> wrote in message
news:km********************************@4ax.com...

On Wed, 7 Jul 2004 14:34:50 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> calmly ranted:

"Gary L. Burnore" <gb******@databasix.com> wrote in message

Overkill, when not required, costs more money, wastes time on the
upstart and causes headaches later. It's not _ALWAYS_ a good thing to
over do it at the start.
It depends on your definition of "over doing". Experience has taught me thatthere are two ways of doing a job - properly or not at all. Doing a "properjob" means having an architecture that will deal with any size of web
application, small or large.

Remember, Tony, that not all of us get the large clients who
give -us- full say in how much the site costs. For the rest of
us, we quote prices for specific goodies, often giving them
one quote for the basics (which 75% of them want) and one quote
for a website with everything on it (including anchovies, which
few want.)

You are still missing the point about using an architecture like mine. Now
that I have spent time and effort in creating all those reusable components
I do not have to do it again. I can simply take the same framework and use
it as the basis for any new site I work on. That way I do not have to keep
re-inventing the wheel for each site. That is what reusability is all
about - write once and use many times. I have a reusable DML class, a
reusable database table class, reusable XSL stylesheets, reusable
dialog-type scripts and a library of reusable functions. I can use the same
framework on any number of different sites without any regard for the size
of those sites. I do not start on a new site with a blank sheet of paper and
rewrite evrything from scratch - that would be grossly inefficient.

If you care to inspect all the other frameworks that are available, for all
languages not just PHP, you will see that they offer the same sort of
functionality - a set of standardised routine which can be used over and
over again on any number of different applications.
Most sole proprietors and mom & pop shops can't afford all the
bells and whistles at one time,
My framework can be used to supply simple nuts-and-bolts applications
without all those expensive bells-and whistles and go-faster stripes. I can
develop web applications faster using my framework than you can without any
framework, and fast development times equates to lower costs to the
customer. That is what RAD (Rapid Application Development) is all about.
so we offer less complete/less
costly sites to get them started. How can that be "wrong" if we
tell them that the original site programing may have to be scrapped
once they get to a certain performance/demand level, and another
more robust model set in its place?
As a customer I would be might pissed off if I was told that my application
could not be enhanced, only rewritten from scratch because it had to use a
different architecture. If a developer cannot create a development framework
that is extensible then he is a pretty poor developer (IMHO).
I'm with Gary on this point
because using your model alone, about 80% of all sites would not
be online today. (Hmmm, in some ways that might not be such a bad
thing after all.) ;>

If each site had to develop my framework from scratch then I would have to
agree. But the whole point is that it has been developed once and does not
need to be developed again, simple reused and reused and reused. That is
where the savings come from.

--
Tony Marston

http://www.tonymarston.net

[Leythos]

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

As a customer I would be might pissed off if I was told that my application
could not be enhanced, only rewritten from scratch because it had to use a
different architecture. If a developer cannot create a development framework
that is extensible then he is a pretty poor developer (IMHO).

I would suggest that your market is narrow, or that you've developed a
framework for what you like to bid on / design around. Having been in
the programming field for 20+ years, I've never seen a framework fit
every customer, and I've seen frameworks applied to projects that could
have been done in less time without the framework.

--
--
sp*********@rrohio.com
(Remove 999 to reply to me)

[Larry Jaques]

On Wed, 7 Jul 2004 21:45:20 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> calmly ranted:

You are still missing the point about using an architecture like mine. Now
that I have spent time and effort in creating all those reusable components
I do not have to do it again. I can simply take the same framework and use
it as the basis for any new site I work on. That way I do not have to keep
re-inventing the wheel for each site. That is what reusability is all
about - write once and use many times. I have a reusable DML class, a
reusable database table class, reusable XSL stylesheets, reusable
dialog-type scripts and a library of reusable functions. I can use the same
framework on any number of different sites without any regard for the size
of those sites. I do not start on a new site with a blank sheet of paper and
rewrite evrything from scratch - that would be grossly inefficient.
Sure, there are lots of reusable code snippets which can be used
on any given site. I'll finish reading all the info on your site
as it's apparent that I missed some of your points.

If you care to inspect all the other frameworks that are available, for all
languages not just PHP, you will see that they offer the same sort of
functionality - a set of standardised routine which can be used over and
over again on any number of different applications.

Most sole proprietors and mom & pop shops can't afford all the
bells and whistles at one time,

My framework can be used to supply simple nuts-and-bolts applications
without all those expensive bells-and whistles and go-faster stripes. I can
develop web applications faster using my framework than you can without any
framework, and fast development times equates to lower costs to the
customer. That is what RAD (Rapid Application Development) is all about.

I think I see where you're coming from now. You're not charging them
for any previously developed coding, just for the current time spent
utilizing the framework?

so we offer less complete/less
costly sites to get them started. How can that be "wrong" if we
tell them that the original site programing may have to be scrapped
once they get to a certain performance/demand level, and another
more robust model set in its place?

As a customer I would be might pissed off if I was told that my application
could not be enhanced, only rewritten from scratch because it had to use a
different architecture. If a developer cannot create a development framework
that is extensible then he is a pretty poor developer (IMHO).

Not if you, the customer, said "Gimme quick 'n dirty, but above
all, give it to me fast and very cheaply." Or don't you get those
people over there? <g>

I'm with Gary on this point
because using your model alone, about 80% of all sites would not
be online today. (Hmmm, in some ways that might not be such a bad
thing after all.) ;>

If each site had to develop my framework from scratch then I would have to
agree. But the whole point is that it has been developed once and does not
need to be developed again, simple reused and reused and reused. That is
where the savings come from.

Gotcha.
----------------------------------------------
Never attempt to traverse a chasm in two leaps
http://www.diversify.com Comprehensive Website Design
================================================== =========

[Tony Marston]

"Larry Jaques" <novalidaddress@di\/ersify.com> wrote in message
news:1g********************************@4ax.com...

On Wed, 7 Jul 2004 21:45:20 +0100, "Tony Marston"
<to**@NOSPAM.demon.co.uk> calmly ranted:

You are still missing the point about using an architecture like mine. Now

that I have spent time and effort in creating all those reusable componentsI do not have to do it again. I can simply take the same framework and useit as the basis for any new site I work on. That way I do not have to keepre-inventing the wheel for each site. That is what reusability is all
about - write once and use many times. I have a reusable DML class, a
reusable database table class, reusable XSL stylesheets, reusable
dialog-type scripts and a library of reusable functions. I can use the sameframework on any number of different sites without any regard for the sizeof those sites. I do not start on a new site with a blank sheet of paper andrewrite evrything from scratch - that would be grossly inefficient.

Sure, there are lots of reusable code snippets which can be used
on any given site. I'll finish reading all the info on your site
as it's apparent that I missed some of your points.

If you care to inspect all the other frameworks that are available, for alllanguages not just PHP, you will see that they offer the same sort of
functionality - a set of standardised routine which can be used over and
over again on any number of different applications.

Most sole proprietors and mom & pop shops can't afford all the
bells and whistles at one time,

My framework can be used to supply simple nuts-and-bolts applications
without all those expensive bells-and whistles and go-faster stripes. I candevelop web applications faster using my framework than you can without anyframework, and fast development times equates to lower costs to the
customer. That is what RAD (Rapid Application Development) is all about.

I think I see where you're coming from now. You're not charging them
for any previously developed coding, just for the current time spent
utilizing the framework?

Now you're geting there. Because I can make use of a large amount of
pre-written code I can develop new applications faster than competitors who
do not have any reusable code. Undercutting competitors while still being
able to produce high quality software is the way to impress paying
customers.

so we offer less complete/less
costly sites to get them started. How can that be "wrong" if we
tell them that the original site programing may have to be scrapped
once they get to a certain performance/demand level, and another
more robust model set in its place?

As a customer I would be might pissed off if I was told that my application

could not be enhanced, only rewritten from scratch because it had to use adifferent architecture. If a developer cannot create a development frameworkthat is extensible then he is a pretty poor developer (IMHO).

Not if you, the customer, said "Gimme quick 'n dirty, but above
all, give it to me fast and very cheaply." Or don't you get those
people over there? <g>

I can build web applications faster by usng my framework than by not using
my framework. If I want to perform a specific function then it is far more
efficient to use code that is pre-written than to write it all over again.
The fact that my framework contains options and capabilities that may exceed
a customer's present requirements is irrelevant. It would cost too much to
identify and extract those unwanted options, so I leave them in. There is
always the chance that the customer may want to take advantage of one of
those options at a later date, and I would not want to go through the hassle
of re-inserting the missing code.

I have worked for software houses for over 20 years, and the trick to
writing one application after another is to develop a reusable and
extensible framework, then reuse it for each new application. It is simply
not cost effective to develop a new framwork for each application.

I'm with Gary on this point
because using your model alone, about 80% of all sites would not
be online today. (Hmmm, in some ways that might not be such a bad
thing after all.) ;>

If each site had to develop my framework from scratch then I would have toagree. But the whole point is that it has been developed once and does notneed to be developed again, simply reused and reused and reused. That is
where the savings come from.

Gotcha.

The penny has dropped at last.

--
Tony Marston

http://www.tonymarston.net

[Tony Marston]

"Leythos" <vo**@nowhere.com> wrote in message
news:MP************************@news-server.columbus.rr.com...

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

As a customer I would be might pissed off if I was told that my application could not be enhanced, only rewritten from scratch because it had to use a different architecture. If a developer cannot create a development framework that is extensible then he is a pretty poor developer (IMHO).
I would suggest that your market is narrow, or that you've developed a
framework for what you like to bid on / design around. Having been in
the programming field for 20+ years, I've never seen a framework fit
every customer,

I have worked in software houses for over 20 years where we developed many
different applications by reusing the same framework. The trick is in the
development of a generic framework that can be used for any application. Not
many developers can pull it off, but some of us can.
and I've seen frameworks applied to projects that could
have been done in less time without the framework.

I still maintain that it is faster to build an application by making use of
pre-written code that it is by having to write each piece of code from
scratch.

--
Tony Marston

http://www.tonymarston.net

[Leythos]

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

I still maintain that it is faster to build an application by making use of
pre-written code that it is by having to write each piece of code from
scratch.

In general you are correct. I have a large library of code that I've
maintained over the decades in order to make it quicker to develop
applications.

When managing a larger team, with on/off shore members, we found that
trying to implement a framework that was suppose to make life easier for
all types of projects to be much more time consuming that mapping it
out, borrowing parts from all of our other projects, coding the new
parts as needed, and then unit testing everything.

In many cases reliance on a framework can get you into trouble by
repeating the same mistake or performance robbing methods over and over.
Complete review of the framework should happen every year or as any new
platform/OS rolls out - and that review time must be accounted for in
your overhead which is then costed into every project.

--
--
sp*********@rrohio.com
(Remove 999 to reply to me)

[Mudge]

Tony Marston wrote:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
which identifies a development environment based on the 3 tier
architecture.

Also look at
http://www.tonymarston.co.uk/php-mys...ontroller.html which
shows how it also incorporates the Model-View-Controller design pattern.

There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can
run online. You can also download all the source code and see how it
ticks. This uses classes for all entity and database access, so it should
give you an idea of what can be done.

It looks complicated, but using the modules that I have created it is
possible to build and maintain web components with much less effort.

HTH.

I also want to thank you for making your web site. It has been extremely
helpfull. I am new to PHP but I have a large Web application that I have in
mind to build so i know that I need to have a very organized structure in
mind to build with.

I am still a pretty knew programmer in general. I know C, PHP, HTML,
Javascript, MySQL, CSS and that's it.

Can you tell me what are the advantages of using OO in developing a web
application using PHP? Why is using OO better in your opinion?

[Tony Marston]

"Leythos" <vo**@nowhere.com> wrote in message
news:MP************************@news-server.columbus.rr.com...

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

I still maintain that it is faster to build an application by making use of pre-written code that it is by having to write each piece of code from
scratch.

In general you are correct. I have a large library of code that I've
maintained over the decades in order to make it quicker to develop
applications.

When managing a larger team, with on/off shore members, we found that
trying to implement a framework that was suppose to make life easier for
all types of projects to be much more time consuming that mapping it
out, borrowing parts from all of our other projects, coding the new
parts as needed, and then unit testing everything.

In many cases reliance on a framework can get you into trouble by
repeating the same mistake or performance robbing methods over and over.
Complete review of the framework should happen every year or as any new
platform/OS rolls out - and that review time must be accounted for in
your overhead which is then costed into every project.

The advantage I found with using a single framework is that once a developer
has become familiar with it, it is easier for that developer to jump into a
new application using that framework. By carefully designing the framework
all the standard code should be in reusable modules, so if a bug or a
performance enhancement appears is should be a simple matter of updating one
or two of those standard modules. The updated modules can then be rolled out
to all the other applications so that they too can take advantage of the
changes. Developers who use a particular framework day in and day out are
also more likely to spot areas where improvements can be made.

The disadvantage of using a team comprised of offshore members that have
never worked with you before is that you have to train them to produce code
to the project standards, otherwise it will be incompatible with what
everyone else is writing. This is true whether you have a framework in mind
or not. Having a suitable framework is only half of the equation - you need
developers who are familiar with that framework so that when a new project
comes along they can hit the ground running.

This is my experience after 20+ years working in software houses.

--
Tony Marston

http://www.tonymarston.net

[Leythos]

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

The disadvantage of using a team comprised of offshore members that have
never worked with you before is that you have to train them to produce code
to the project standards, otherwise it will be incompatible with what
everyone else is writing. This is true whether you have a framework in mind
or not. Having a suitable framework is only half of the equation - you need
developers who are familiar with that framework so that when a new project
comes along they can hit the ground running.

This is my experience after 20+ years working in software houses.

This is my experience too - the framework requires training, and
maintenance, which you must figure into the overhead, which you must
figure into the hourly rate....

We're on the same page, frameworks are great, but there are downsides to
them also - more than just training.

--
--
sp*********@rrohio.com
(Remove 999 to reply to me)

[Tony Marston]

"Leythos" <vo**@nowhere.com> wrote in message
news:MP************************@news-server.columbus.rr.com...

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

The disadvantage of using a team comprised of offshore members that have
never worked with you before is that you have to train them to produce code to the project standards, otherwise it will be incompatible with what
everyone else is writing. This is true whether you have a framework in mind or not. Having a suitable framework is only half of the equation - you need developers who are familiar with that framework so that when a new project comes along they can hit the ground running.

This is my experience after 20+ years working in software houses.

This is my experience too - the framework requires training, and
maintenance, which you must figure into the overhead, which you must
figure into the hourly rate....

We're on the same page, frameworks are great, but there are downsides to
them also - more than just training.

Just try develping an application without any sort of framework to start
with and you will be in a bigger mess. You then have to develop a framework
AND train all your staff how to use it.

If you keep using new staff on each new project you will have to train them
each time, framework or no framework. You can get better savings by reusing
the same team of developers who are then able to reuse the same framework.
If you start from scratch with each new project then your start-up costs
will always be much higher. So you can achieve the highest savings by having
a reusable framework AND a reusable development team.

--
Tony Marston

http://www.tonymarston.net

[Jeffrey Silverman]

On Thu, 08 Jul 2004 05:31:27 +0000, Mudge wrote:

I am still a pretty knew programmer in general. I know C, PHP, HTML,
Javascript, MySQL, CSS and that's it.

Isn't that enough?

But seriously, though, I can't imagine how any one person can become a
true expert with more than a few programming languages at a time. Also, if
the tool works, why do you need to know how to use a huge array of other
tools? Especially when other tools are very similar. Also, also, if you
have a specific situation that requires the use a tool you do not already
know, then learn it then. Basic programming practice and procedures apply
pretty well to all programming languages. It's a matter of degree.

--
Jeffrey D. Silverman | je*****@pantsjhu.edu **
Website | http://www.newtnotes.com

(** Drop "pants" to reply by email)

[Me]

Man, did start something here, or what?
Tony~
I may be new to PHP, but not to the development world in general. I am
still struggling a bit with the architecture which you laid out in your
site, but I think I can latch onto it. I'm a little amazed at how large
a can I opened by asking the question. I've been on both the front end
and the back end of a number of projects, and I have to agree that
re-usable components are the shortest distance between two points. I
have been a developer on a number of RAD projects ('Crunch Mode') they
used to call it, and have seen teams struggle with the scratch built
concept. I do believe that the front end should be seperated from the
back end as much as possible, and I have been in meetings where
programmers were let go because it was discovered that an application
under development would not scale to the clients end requirements.
As to the site that I have inherited, the colors were chosen by the
executive officers, so that's a wash. I do know that the display is not
being presented uniformly across platforms (a problem which I'm not sure
how to resolve at the moment), but, with all of the different sections
(and four more to be added), and the addition of the services and
supplements sections, I know first-hand that this site has already grown
well beyond the point of manual maintenance. I need to get the
redevelopment underway and would like to implement your architecture to
do so, since there are other parts of the site (mapping, user tracking,
site search, etc) that need to be integrated, and will only make a
horredndous maintenance job that much more complicated. My point in the
earlier post was that, as a data entry/maintenance app, the sample
presents the ideas you have quite well, but the site that I need to work
on has only the view side to contend with at the moment (although,
administration of all that data is certainly one which has to be
tackled). I'm continuing my review of the subject matter on your site
in hopes that the light goes on giving me a starting point (which, my
guess is at the database level designing the tables and relationships
ws which will house the data for the site). Any thought are greatly
appreciated.

Regards,

John

On Thu, 08 Jul 2004 14:35:43 +0100, Tony Marston wrote:

"Leythos" <vo**@nowhere.com> wrote in message
news:MP************************@news-server.columbus.rr.com...

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...

> The disadvantage of using a team comprised of offshore members that have
> never worked with you before is that you have to train them to produce code > to the project standards, otherwise it will be incompatible with what
> everyone else is writing. This is true whether you have a framework in mind > or not. Having a suitable framework is only half of the equation - you need > developers who are familiar with that framework so that when a new project > comes along they can hit the ground running.
>
> This is my experience after 20+ years working in software houses.

This is my experience too - the framework requires training, and
maintenance, which you must figure into the overhead, which you must
figure into the hourly rate....

We're on the same page, frameworks are great, but there are downsides to
them also - more than just training.

Just try develping an application without any sort of framework to start
with and you will be in a bigger mess. You then have to develop a framework
AND train all your staff how to use it.

If you keep using new staff on each new project you will have to train them
each time, framework or no framework. You can get better savings by reusing
the same team of developers who are then able to reuse the same framework.
If you start from scratch with each new project then your start-up costs
will always be much higher. So you can achieve the highest savings by having
a reusable framework AND a reusable development team.

[Tim Tyler]

Tony Marston <to**@nospam.demon.co.uk> wrote or quoted:

Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
which identifies a development environment based on the 3 tier architecture.
[...]
There is a sample application based on these architectures described in
http://www.tonymarston.net/php-mysql...plication.html which you can
run online. You can also download all the source code and see how it ticks.
This uses classes for all entity and database access, so it should give you
an idea of what can be done.

Your site is great Tony.

http://www.tonymarston.net/sample/person_list.php

Brief critical feedback:

When evaluating such libraries, I look at two things first:

I look at *examples*, to see whether any of them can be bent
into whatever shape I am trying to make.

....and I look at the *license* terms - to see if I can use the
code at all - or whether (for example) the code is GPL'd -
and contains too many restrictions on its use for me to be
able to pass on to clients.

The most complex example I could find was:

http://www.tonymarston.net/sample/person_list.php

I typically want to see examples that do more practical things.

Discussion forums, RSS feeds, news broadcasting, handling
authentication of users, searching - that sort of thing.

Also, there was no discussion of the license terms for the
code that I could find (without downloading the code).

In my case the second issue was a rather terminal failing:
unable to easily find any statement relating to copyright or
licensing, I wrote this message and then moved on.

Best wishes,
--
__________
|im |yler http://timtyler.org/ ti*@tt1lock.org Remove lock to reply.

[Me]

On Wed, 07 Jul 2004 11:45:33 +0100, Tony Marston wrote:

You do not use different architectures for different sizes of application. A
small application may grow into a large application over time, and you don't
want to switch architectures in mid stream.
Agreed. Scalable is better in the long run than having to scramble and
re-design.
In order to provide the benefits of a RAD (Rapid Application
Development) environment what you need is a series of components that
provide standard functionality in a reusable form. If you look at Figure
5 in http://www.tonymarston.co.uk/php-mys...e.html#figure5
you will see what looks like a very complicated architecture, but the
following parts have already been written and are waiting to be used: - Yes, I do see that.
the abstract table class
- the validation class
- the DML class
- dialog type scripts
- generic XSL files
- a default CSS file
The 'super-set', if you will.
To build a component all you have to do is the following:- - For each
database table construct a subclass which extends the abstract table
class. As a bare minimum this simply describes the structure of that
database table.
- Construct a component script which identifies three things:
a) Which business entity (database table) to use - this is the Model
part of MVC.
b) Which screen structure script to use - this is the View part of MVC.
c) Which dialog type script to use - this is the controller part of MVC.

You should be able to recognise that the complicated part has already
been done so that the construction of new components is made as simple
as possible.
Absolutely. This is where I'm trying to get to in my development
experience.
You may be interested to know that I have already extended my software
to include a Role Based Access Control (RBAC) system, an Audit Trail
system and a Workflow system, so that proves how extensible it is.
Is this to be included in some point on your site?
The colours are a bit dark and gloomy, and I personally do not like the
use of client-side scripting (especially ActiveX controls) which is why
I have those options turned off. Consequently parts of your website did
not display as you intended.

As stated, the powers that be liked it, and it's not my place to alter it
(yet), so the general layout is what I'm stuck with at the moment. I
wasn't aware that client-side scripting is on here, except for the
javascript files which are running. They don't really 'do' much, and I
would like to eventually have those gone as well, at least as much as
possible.

Thank you again for your help. I seem to be learning more from your web site each time I read through it...

It is nice to know that my humble efforts are appreciated.

I'm currently going through the model to decide on the entities and their
relationships. I figured this to be the place to start, but it seems as
though you handle the subclasses, component scripts, screen structures,
and dialog types in parallel. Is that correct?

[Tony Marston]

"Me" <jd******@atlantic.net> wrote in message
news:pa****************************@atlantic.net.. .

Man, did start something here, or what?
Tony~
I may be new to PHP, but not to the development world in general. I am
still struggling a bit with the architecture which you laid out in your
site, but I think I can latch onto it.
Every new architecture looks complicated at first. It is only by running the
sample code that you can follow the logic and judge if it is suitable for
you. The next step is to create a new database table and see how long it
takes you to create components which can maintain it.
I'm a little amazed at how large
a can I opened by asking the question.
It just goes to show how varied opinions can be and that there is no "one
true architecture". Different people try to reach the same objective in
different ways, each with their own level of complexity, efficiency and
scalability. It is your choice as to which one you use - unless of course
you become an employee in an organisation and they force you to adopt their
choice.
I've been on both the front end
and the back end of a number of projects, and I have to agree that
re-usable components are the shortest distance between two points. I
have been a developer on a number of RAD projects ('Crunch Mode') they
used to call it, and have seen teams struggle with the scratch built
concept. I do believe that the front end should be seperated from the
back end as much as possible, and I have been in meetings where
programmers were let go because it was discovered that an application
under development would not scale to the clients end requirements.
I was once on a project where the system architects (who were supposed to be
my superiors) designed and built an infrastructure that in theory was
absolutely brilliant. It contained all the right buzzwords (3 tier
architecure, separate application model for te presentation layer, object
oriented design) but sufferred from one minor flaw - it took two weeks to
build each individual component. The client was so impressed by the effect
on his bufget and his timescales that he cancelled the whole project.

To me the effectiveness of an architecture is not how many buzzwords you can
use when describing it, but how quickly you can develop components with it.
I have designed and built development infrastructures in 3 different
languages and I have consistently achieved development times in hours or
minutes rather than days or weeks.
As to the site that I have inherited, the colors were chosen by the
executive officers, so that's a wash. I do know that the display is not
being presented uniformly across platforms (a problem which I'm not sure
how to resolve at the moment),
If you stick to pure (X)HTML and simple CSS, and avoid such things as
javascript and ActiveX controls, you should have a site that renders the
same whatever browser is being used - provided that it is a browser that
conforms to the current W3C standards.
but, with all of the different sections
(and four more to be added), and the addition of the services and
supplements sections, I know first-hand that this site has already grown
well beyond the point of manual maintenance. I need to get the
redevelopment underway and would like to implement your architecture to
do so, since there are other parts of the site (mapping, user tracking,
site search, etc) that need to be integrated, and will only make a
horredndous maintenance job that much more complicated. My point in the
earlier post was that, as a data entry/maintenance app, the sample
presents the ideas you have quite well, but the site that I need to work
on has only the view side to contend with at the moment (although,
administration of all that data is certainly one which has to be
tackled). I'm continuing my review of the subject matter on your site
in hopes that the light goes on giving me a starting point (which, my
guess is at the database level designing the tables and relationships
ws which will house the data for the site). Any thought are greatly
appreciated.
The most important part of any application is the database design - if you
get that wrong you are screwed from the start. Then you need a class for
each database table (business entity) that contains the business rules for
that table/entity. Then you construct components (utilising as many
pre-written reusable modules as possible) to display and maintain the
contents of those database tables.

Easy peasy lemon squeezy.

--
Tony Marston

http://www.tonymarston.net
On Thu, 08 Jul 2004 14:35:43 +0100, Tony Marston wrote:

"Leythos" <vo**@nowhere.com> wrote in message
news:MP************************@news-server.columbus.rr.com...

In article <cc*******************@news.demon.co.uk>,
to**@NOSPAM.demon.co.uk says...
> The disadvantage of using a team comprised of offshore members that have > never worked with you before is that you have to train them to produce

code

> to the project standards, otherwise it will be incompatible with what
> everyone else is writing. This is true whether you have a framework

in mind

> or not. Having a suitable framework is only half of the equation -

you need

> developers who are familiar with that framework so that when a new

project

> comes along they can hit the ground running.
>
> This is my experience after 20+ years working in software houses.

This is my experience too - the framework requires training, and
maintenance, which you must figure into the overhead, which you must
figure into the hourly rate....

We're on the same page, frameworks are great, but there are downsides

to them also - more than just training.

Just try develping an application without any sort of framework to start
with and you will be in a bigger mess. You then have to develop a

framework AND train all your staff how to use it.

If you keep using new staff on each new project you will have to train them each time, framework or no framework. You can get better savings by reusing the same team of developers who are then able to reuse the same framework. If you start from scratch with each new project then your start-up costs
will always be much higher. So you can achieve the highest savings by having a reusable framework AND a reusable development team.

[Tony Marston]

"Me" <jd******@atlantic.net> wrote in message
news:pa****************************@atlantic.net.. .

On Wed, 07 Jul 2004 11:45:33 +0100, Tony Marston wrote:

You do not use different architectures for different sizes of application. A

small application may grow into a large application over time, and you don't want to switch architectures in mid stream.

Agreed. Scalable is better in the long run than having to scramble and
re-design.

In order to provide the benefits of a RAD (Rapid Application
Development) environment what you need is a series of components that
provide standard functionality in a reusable form. If you look at Figure
5 in http://www.tonymarston.co.uk/php-mys...e.html#figure5
you will see what looks like a very complicated architecture, but the
following parts have already been written and are waiting to be used:

Yes, I do see that.

- the abstract table class
- the validation class
- the DML class
- dialog type scripts
- generic XSL files
- a default CSS file

The 'super-set', if you will.

Correct. I have invested a great deal of time and effort in designing,
building and testing these reusable modules, and the investment pays off
each time I reuse them in a new component.

To build a component all you have to do is the following:- - For each
database table construct a subclass which extends the abstract table
class. As a bare minimum this simply describes the structure of that
database table.
- Construct a component script which identifies three things:
a) Which business entity (database table) to use - this is the Model
part of MVC.
b) Which screen structure script to use - this is the View part of MVC.
c) Which dialog type script to use - this is the controller part of MVC.

You should be able to recognise that the complicated part has already
been done so that the construction of new components is made as simple
as possible.

Absolutely. This is where I'm trying to get to in my development
experience.

Unfortunately this is not something a novice can learn on his/her own. It
comes with years of experence and a great deal of trial and error. You need
to use a range of different architectures in order to see their strengths
and weaknesses, then choose one that is the most suitable. In my case I have
stopped using other people's architectures as I can do much better by
"rolling my own".

You may be interested to know that I have already extended my software
to include a Role Based Access Control (RBAC) system, an Audit Trail
system and a Workflow system, so that proves how extensible it is.

Is this to be included in some point on your site?

I have not decided yet. I am still in the process of documenting the 60+
screens in my RBAC system before I publish the URL which will give access to
a demonstration version. I then need to produce the documentation for my
Audit and Workflow systems. I have not yet decided whther I want to give
this code out for free as I need to make a livingt out of it somehow.

The colours are a bit dark and gloomy, and I personally do not like the
use of client-side scripting (especially ActiveX controls) which is why
I have those options turned off. Consequently parts of your website did
not display as you intended.

As stated, the powers that be liked it, and it's not my place to alter it
(yet), so the general layout is what I'm stuck with at the moment. I
wasn't aware that client-side scripting is on here, except for the
javascript files which are running. They don't really 'do' much, and I
would like to eventually have those gone as well, at least as much as
possible.
Thank you again for your help. I seem to be learning more from your web site each time I read through it...

It is nice to know that my humble efforts are appreciated.

I'm currently going through the model to decide on the entities and their
relationships. I figured this to be the place to start, but it seems as
though you handle the subclasses, component scripts, screen structures,
and dialog types in parallel. Is that correct?

More or less. Each user request identifies a particular component script.

Each component script sets one or more variables identifying which database
tables (model) to use and which screen structure (view) to use, then it
passes control to one of my dialog-type (controller) scripts.

The dialog-type script processes the HTTP request and issues a response. It
communicates with the specified database table subclasses and creates a
response in the form of an XML file. The screen structure file identifies
which generic XSL file to use to transform the XML file into (X)HTML output.

Each database table class is actually a subclass of my generic table class.
The "superclass" contains code which can be used on any database table while
each "subclass" contains only that code which is specific to that particular
table.

My database table "superclass" talks to the physical database through a DML
class which is specific to a particular database engine. I have one class
for MySQL, and should it be necessary I can create separate classes for
other database engines. This gives me the option of switching from one
database engine to another simply by nominating a different DML class - do
not have to go through the entire application and make changes in multiple
places.

As you can see each HTTP request uses a variety of modules. Different
modules are used in different combinations to produce a particular result.

--
Tony Marston

http://www.tonymarston.net

[Me]

On Sun, 11 Jul 2004 12:29:04 +0100, Tony Marston wrote:

I'm continuing my review of the subject matter on your site
in hopes that the light goes on giving me a starting point (which, my
guess is at the database level designing the tables and relationships
ws which will house the data for the site). Any thought are greatly
appreciated.

The most important part of any application is the database design - if you
get that wrong you are screwed from the start. Then you need a class for
each database table (business entity) that contains the business rules for
that table/entity. Then you construct components (utilising as many
pre-written reusable modules as possible) to display and maintain the
contents of those database tables.

Easy peasy lemon squeezy.

I like that quote...
I've started on the ERD and have a baseline which I'm going to groom a
little before deciding its a good start point. I'm going to try and
develop the components and scripts as well, just to get a feel for how to
work in this architecture. I'll let you know how I make out.

Thanks

[Tony Marston]

"Me" <jd******@atlantic.net> wrote in message
news:pa****************************@atlantic.net.. .

On Sun, 11 Jul 2004 12:29:04 +0100, Tony Marston wrote:

I'm continuing my review of the subject matter on your site
in hopes that the light goes on giving me a starting point (which, my
guess is at the database level designing the tables and relationships
ws which will house the data for the site). Any thought are greatly
appreciated.

The most important part of any application is the database design - if you get that wrong you are screwed from the start. Then you need a class for
each database table (business entity) that contains the business rules for that table/entity. Then you construct components (utilising as many
pre-written reusable modules as possible) to display and maintain the
contents of those database tables.

Easy peasy lemon squeezy.

I like that quote...

I've started on the ERD and have a baseline which I'm going to groom a
little before deciding its a good start point. I'm going to try and
develop the components and scripts as well, just to get a feel for how to
work in this architecture. I'll let you know how I make out.

Thanks

Good luck. I hope my sample application can give you some useful pointers.

--
Tony Marston

http://www.tonymarston.net