PHP site development

[Tony Marston]

Re: PHP site development


"Leythos" <void@nowhere.c om> wrote in message
news:MPG.1b562f 96feb553b798a77 5@news-server.columbus .rr.com...[color=blue]
> In article <cchnd1$lkp$1$8 30fa795@news.de mon.co.uk>,
> tony@NOSPAM.dem on.co.uk says...[color=green]
> > As a customer I would be might pissed off if I was told that my[/color][/color]
application[color=blue][color=green]
> > could not be enhanced, only rewritten from scratch because it had to use[/color][/color]
a[color=blue][color=green]
> > different architecture. If a developer cannot create a development[/color][/color]
framework[color=blue][color=green]
> > that is extensible then he is a pretty poor developer (IMHO).[/color]
>
> 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,[/color]

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.
[color=blue]
> and I've seen frameworks applied to projects that could
> have been done in less time without the framework.[/color]

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]

Re: PHP site development

In article <cci6b8$p9n$1$8 300dec7@news.de mon.co.uk>,
tony@NOSPAM.dem on.co.uk says...[color=blue]
> 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.[/color]

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.

--
--
spamfree999@rro hio.com
(Remove 999 to reply to me)

[Mudge]

Re: PHP site development

Tony Marston wrote:
[color=blue]
> 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.
>[/color]

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]

Re: PHP site development


"Leythos" <void@nowhere.c om> wrote in message
news:MPG.1b566a d98d18ef3b98a77 8@news-server.columbus .rr.com...[color=blue]
> In article <cci6b8$p9n$1$8 300dec7@news.de mon.co.uk>,
> tony@NOSPAM.dem on.co.uk says...[color=green]
> > I still maintain that it is faster to build an application by making use[/color][/color]
of[color=blue][color=green]
> > pre-written code that it is by having to write each piece of code from
> > scratch.[/color]
>
> 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.[/color]

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]

Re: PHP site development

In article <ccj5vi$39f$1$8 300dec7@news.de mon.co.uk>,
tony@NOSPAM.dem on.co.uk says...[color=blue]
> 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.[/color]

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.

--
--
spamfree999@rro hio.com
(Remove 999 to reply to me)

[Tony Marston]

Re: PHP site development


"Leythos" <void@nowhere.c om> wrote in message
news:MPG.1b5708 502083e7b898a77 c@news-server.columbus .rr.com...[color=blue]
> In article <ccj5vi$39f$1$8 300dec7@news.de mon.co.uk>,
> tony@NOSPAM.dem on.co.uk says...[color=green]
> > 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[/color][/color]
code[color=blue][color=green]
> > to the project standards, otherwise it will be incompatible with what
> > everyone else is writing. This is true whether you have a framework in[/color][/color]
mind[color=blue][color=green]
> > or not. Having a suitable framework is only half of the equation - you[/color][/color]
need[color=blue][color=green]
> > developers who are familiar with that framework so that when a new[/color][/color]
project[color=blue][color=green]
> > comes along they can hit the ground running.
> >
> > This is my experience after 20+ years working in software houses.[/color]
>
> 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.[/color]

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]

Re: PHP site development

On Thu, 08 Jul 2004 05:31:27 +0000, Mudge wrote:
[color=blue]
> I am still a pretty knew programmer in general. I know C, PHP, HTML,
> Javascript, MySQL, CSS and that's it.[/color]

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 | jeffrey@pantsjh u.edu **
Website | http://www.newtnotes.com

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

[Me]

Re: PHP site development

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:
[color=blue]
>
> "Leythos" <void@nowhere.c om> wrote in message
> news:MPG.1b5708 502083e7b898a77 c@news-server.columbus .rr.com...[color=green]
>> In article <ccj5vi$39f$1$8 300dec7@news.de mon.co.uk>,
>> tony@NOSPAM.dem on.co.uk says...[color=darkred]
>> > 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[/color][/color]
> code[color=green][color=darkred]
>> > to the project standards, otherwise it will be incompatible with what
>> > everyone else is writing. This is true whether you have a framework in[/color][/color]
> mind[color=green][color=darkred]
>> > or not. Having a suitable framework is only half of the equation - you[/color][/color]
> need[color=green][color=darkred]
>> > developers who are familiar with that framework so that when a new[/color][/color]
> project[color=green][color=darkred]
>> > comes along they can hit the ground running.
>> >
>> > This is my experience after 20+ years working in software houses.[/color]
>>
>> 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.[/color]
>
> 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.[/color]

[Tim Tyler]

Re: PHP site development

Tony Marston <tony@nospam.de mon.co.uk> wrote or quoted:
[color=blue]
> Take a look at http://www.tonymarston.co.uk/php-mys...structure.html
> which identifies a development environment based on the 3 tier architecture.[/color]

[...]
[color=blue]
> 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.[/color]

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/ tim@tt1lock.org Remove lock to reply.

[Me]

Re: PHP site development

On Wed, 07 Jul 2004 11:45:33 +0100, Tony Marston wrote:
[color=blue]
> 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.
>[/color]
Agreed. Scalable is better in the long run than having to scramble and
re-design.
[color=blue]
> 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: -[/color]
Yes, I do see that.
[color=blue]
> the abstract table class
> - the validation class
> - the DML class
> - dialog type scripts
> - generic XSL files
> - a default CSS file
>[/color]
The 'super-set', if you will.
[color=blue]
> 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.[/color]

Absolutely. This is where I'm trying to get to in my development
experience.
[color=blue]
> 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.
>[/color]
Is this to be included in some point on your site?
[color=blue]
> 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.
>[/color]

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.
[color=blue][color=green]
>> Thank you again for your help. I seem to be learning more from[/color][/color]
your[color=blue][color=green]
>> web site each time I read through it...[/color]
>
> It is nice to know that my humble efforts are appreciated.[/color]

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]

Re: PHP site development


"Me" <jdangler@atlan tic.net> wrote in message
news:pan.2004.0 7.11.01.48.19.3 23931@atlantic. net...[color=blue]
> 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.[/color]

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.
[color=blue]
> I'm a little amazed at how large
> a can I opened by asking the question.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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),[/color]

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.
[color=blue]
> 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.[/color]

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

[color=blue]
> On Thu, 08 Jul 2004 14:35:43 +0100, Tony Marston wrote:
>[color=green]
> >
> > "Leythos" <void@nowhere.c om> wrote in message
> > news:MPG.1b5708 502083e7b898a77 c@news-server.columbus .rr.com...[color=darkred]
> >> In article <ccj5vi$39f$1$8 300dec7@news.de mon.co.uk>,
> >> tony@NOSPAM.dem on.co.uk says...
> >> > The disadvantage of using a team comprised of offshore members that[/color][/color][/color]
have[color=blue][color=green][color=darkred]
> >> > never worked with you before is that you have to train them to[/color][/color][/color]
produce[color=blue][color=green]
> > code[color=darkred]
> >> > to the project standards, otherwise it will be incompatible with what
> >> > everyone else is writing. This is true whether you have a framework[/color][/color][/color]
in[color=blue][color=green]
> > mind[color=darkred]
> >> > or not. Having a suitable framework is only half of the equation -[/color][/color][/color]
you[color=blue][color=green]
> > need[color=darkred]
> >> > developers who are familiar with that framework so that when a new[/color]
> > project[color=darkred]
> >> > 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[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> >> them also - more than just training.[/color]
> >
> > 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[/color][/color]
framework[color=blue][color=green]
> > AND train all your staff how to use it.
> >
> > If you keep using new staff on each new project you will have to train[/color][/color]
them[color=blue][color=green]
> > each time, framework or no framework. You can get better savings by[/color][/color]
reusing[color=blue][color=green]
> > the same team of developers who are then able to reuse the same[/color][/color]
framework.[color=blue][color=green]
> > 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[/color][/color]
having[color=blue][color=green]
> > a reusable framework AND a reusable development team.[/color]
>[/color]

[Tony Marston]

Re: PHP site development


"Me" <jdangler@atlan tic.net> wrote in message
news:pan.2004.0 7.11.06.02.50.2 23623@atlantic. net...[color=blue]
> On Wed, 07 Jul 2004 11:45:33 +0100, Tony Marston wrote:
>[color=green]
> > You do not use different architectures for different sizes of[/color][/color]
application. A[color=blue][color=green]
> > small application may grow into a large application over time, and you[/color][/color]
don't[color=blue][color=green]
> > want to switch architectures in mid stream.
> >[/color]
> Agreed. Scalable is better in the long run than having to scramble and
> re-design.
>[color=green]
> > 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:[/color]
> Yes, I do see that.
>[color=green]
> > - the abstract table class
> > - the validation class
> > - the DML class
> > - dialog type scripts
> > - generic XSL files
> > - a default CSS file
> >[/color]
> The 'super-set', if you will.[/color]

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.
[color=blue][color=green]
> > 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.[/color]
>
> Absolutely. This is where I'm trying to get to in my development
> experience.[/color]

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".
[color=blue][color=green]
> > 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.
> >[/color]
> Is this to be included in some point on your site?[/color]

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.
[color=blue][color=green]
> > 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.
> >[/color]
>
> 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.
>[color=green][color=darkred]
> >> Thank you again for your help. I seem to be learning more from[/color][/color]
> your[color=green][color=darkred]
> >> web site each time I read through it...[/color]
> >
> > It is nice to know that my humble efforts are appreciated.[/color]
>
> 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?[/color]

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]

Re: PHP site development

On Sun, 11 Jul 2004 12:29:04 +0100, Tony Marston wrote:
[color=blue]
>[color=green]
>>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.[/color]
>
> 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.[/color]
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]

Re: PHP site development


"Me" <jdangler@atlan tic.net> wrote in message
news:pan.2004.0 7.12.00.07.57.2 45569@atlantic. net...[color=blue]
> On Sun, 11 Jul 2004 12:29:04 +0100, Tony Marston wrote:
>[color=green]
> >[color=darkred]
> >>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.[/color]
> >
> > The most important part of any application is the database design - if[/color][/color]
you[color=blue][color=green]
> > 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[/color][/color]
for[color=blue][color=green]
> > 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.[/color]
>
> 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[/color]

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

--
Tony Marston

http://www.tonymarston.net