Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #15925 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2015-12-19 10:03 +0000 |
| Last post | 2016-01-12 05:34 +0100 |
| Articles | 20 on this page of 159 — 11 participants |
Back to article view | Back to comp.lang.php
PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-19 10:03 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-19 08:20 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-20 10:16 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 09:31 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-20 17:11 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 16:42 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-25 15:56 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-25 11:23 -0500
Re: PHP boilerplate to appear at the top of any program James Harris <james.harris.1@gmail.com> - 2015-12-26 10:09 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-26 09:33 -0500
Re: PHP boilerplate to appear at the top of any program Denis McMahon <denismfmcmahon@gmail.com> - 2015-12-20 22:54 +0000
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-20 18:40 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 10:38 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 08:41 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 15:30 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 11:04 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 23:24 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:16 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 00:33 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:19 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 10:27 +0100
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 11:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 06:34 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 16:00 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 10:56 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 15:56 +0100
OT: pre-PHP day (was: PHP boilerplate to appear at the top of any program) Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 16:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:03 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-22 18:02 +0100
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 14:47 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:04 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:22 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:33 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:46 +0100
Re: PHP boilerplate to appear at the top of any program "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-12-21 17:25 +0100
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-21 23:17 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:23 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-28 15:26 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 10:02 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 18:14 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 12:29 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 18:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 14:15 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-28 21:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 15:49 -0500
Re: PHP boilerplate to appear at the top of any program Richard Damon <Richard@Damon-Family.org> - 2015-12-28 20:31 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 20:48 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 11:26 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 12:33 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 18:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:14 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-30 19:05 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:18 -0500
Re: PHP boilerplate to appear at the top of any program Richard Damon <Richard@Damon-Family.org> - 2015-12-30 21:55 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-30 22:14 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:43 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:46 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 22:42 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:07 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 07:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 16:11 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 10:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 17:43 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:49 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 20:35 +0100
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 11:18 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 12:36 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-30 19:09 +0100
Re: PHP boilerplate to appear at the top of any program Thomas Mlynarczyk <thomas@mlynarczyk-webdesign.de> - 2015-12-30 20:28 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:09 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-30 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 09:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 07:53 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 16:03 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 10:49 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-31 17:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:54 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-31 20:41 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 14:47 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 20:56 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 15:21 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-31 17:52 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-31 13:51 -0500
Re: PHP boilerplate to appear at the top of any program Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-12-28 19:35 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-28 14:17 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 00:20 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:27 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 10:12 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 06:36 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 13:57 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 11:05 -0500
Re: PHP boilerplate to appear at the top of any program Gregor Kofler <usenet@gregorkofler.com> - 2015-12-22 17:22 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:01 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2015-12-22 18:25 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 12:34 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-21 14:53 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 19:30 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:40 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:47 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 21:55 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2015-12-21 21:57 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 22:01 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-21 21:54 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-22 11:54 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 15:42 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-02 11:08 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-02 15:12 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 10:41 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 14:39 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2015-12-22 11:49 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-22 15:44 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-02 11:09 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-02 15:14 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 10:42 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 14:41 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-04 22:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 19:40 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:19 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:29 -0500
Re: PHP boilerplate to appear at the top of any program Matthew Carter <m@ahungry.com> - 2016-01-05 02:02 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 09:08 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 18:55 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:06 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-04 15:51 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 19:41 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:27 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:31 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 04:48 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-04 22:52 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 09:16 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 09:08 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 18:59 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:07 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 01:13 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 20:52 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 08:53 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 09:15 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-05 09:00 -0800
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-05 19:01 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:09 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 01:15 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 20:51 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-06 08:54 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 09:16 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:02 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:02 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:42 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:44 -0500
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-05 14:09 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-06 09:27 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 15:25 -0500
Re: PHP boilerplate to appear at the top of any program Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2016-01-06 13:27 -0800
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-06 16:32 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 09:03 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 08:03 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-11 23:45 +0100
Re: PHP boilerplate to appear at the top of any program Jerry Stuckle <jstucklex@attglobal.net> - 2016-01-11 20:48 -0500
Re: PHP boilerplate to appear at the top of any program Arno Welzel <usenet@arnowelzel.de> - 2016-01-12 05:34 +0100
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-12-19 10:03 +0000 |
| Subject | PHP boilerplate to appear at the top of any program |
| Message-ID | <n539sr$a82$1@dont-email.me> |
In the interests of getting a consistent approach to developing PHP
programs do you guys have any guidelines you follow and/or boilerplate
you include when writing a new piece of PHP? For HTML output I mean
things like the following.
At the top of the code: setup such as error_reporting, ini_set etc and
constant definitions.
Use of ob_start before the code generates 'normal' output so that the
program can present custom error information if something goes wrong.
A fail() function which will ob_end_clean and then render a suitable
failure HTML page.
Some sort of debugging functions which will work with output buffer
capture to generate sensible debug output.
Is there anything else that should be present at the top of a piece of code?
Given the fact that some of the above may vary between environments such
as test and production is it feasible to pull in something like the
above with
require_once("preamble_code.php");
I have code such as the above at the moment but for various reasons it
is not completely satisfactory. I wondered if people who were more
familiar with PHP had come up with a better approach.
If some of the above can be parameterised might it even be possible to
come up with a universal module that can be pulled in with require_once
(and then the functions within it called with certain parameters)?
James
[toc] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-19 08:20 -0500 |
| Message-ID | <n53lek$g0a$1@jstuckle.eternal-september.org> |
| In reply to | #15925 |
Please see below:
On 12/19/2015 5:03 AM, James Harris wrote:
> In the interests of getting a consistent approach to developing PHP
> programs do you guys have any guidelines you follow and/or boilerplate
> you include when writing a new piece of PHP? For HTML output I mean
> things like the following.
>
> At the top of the code: setup such as error_reporting, ini_set etc and
> constant definitions.
>
I do not change error_reporting or any ini_set. Terrible form. These
should be set correctly in your php.ini file. And constants, etc. are
set as necessary.
> Use of ob_start before the code generates 'normal' output so that the
> program can present custom error information if something goes wrong.
>
Needing to use ob_start is needless overhead and indicates poor design
of your code.
> A fail() function which will ob_end_clean and then render a suitable
> failure HTML page.
>
See above.
> Some sort of debugging functions which will work with output buffer
> capture to generate sensible debug output.
>
See above.
> Is there anything else that should be present at the top of a piece of
> code?
>
Only what is necessary.
> Given the fact that some of the above may vary between environments such
> as test and production is it feasible to pull in something like the
> above with
>
> require_once("preamble_code.php");
>
I include my own class files and files with database userid/passwords
(which are stored outside of the DOCUMENT_ROOT). I don't have a
standard preamble.
> I have code such as the above at the moment but for various reasons it
> is not completely satisfactory. I wondered if people who were more
> familiar with PHP had come up with a better approach.
>
Probably because it's a bad idea.
> If some of the above can be parameterised might it even be possible to
> come up with a universal module that can be pulled in with require_once
> (and then the functions within it called with certain parameters)?
>
> James
Just get rid of it. You'll be better off in the long run.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-12-20 10:16 +0000 |
| Message-ID | <n55v1a$rbf$1@dont-email.me> |
| In reply to | #15926 |
On 19/12/2015 13:20, Jerry Stuckle wrote:
> Please see below:
>
> On 12/19/2015 5:03 AM, James Harris wrote:
>> In the interests of getting a consistent approach to developing PHP
>> programs do you guys have any guidelines you follow and/or boilerplate
>> you include when writing a new piece of PHP? For HTML output I mean
>> things like the following.
>>
>> At the top of the code: setup such as error_reporting, ini_set etc and
>> constant definitions.
>>
>
> I do not change error_reporting or any ini_set. Terrible form. These
> should be set correctly in your php.ini file. And constants, etc. are
> set as necessary.
Why is that "terrible form"? For one thing, I am not sure that I will
always have update access to the php.ini file of a given hosting
service, and I would rather the PHP program be portable. For another,
could a given system not have two programs which need at least some
different ini settings? For example, if developing a certain program I
might begin it with
error_reporting(E_ALL);
ini_set("log_errors", "1");
ini_set("display_errors", "1");
That program could exist alongside others that were already developed
and which did not need such debugging.
>> Use of ob_start before the code generates 'normal' output so that the
>> program can present custom error information if something goes wrong.
>>
>
> Needing to use ob_start is needless overhead and indicates poor design
> of your code.
What you say suggests either that it's OK for errors to happen midway
through the code (after some of the page has been produced) or that the
code has the form:
1. Do all error checking
2. Produce the web page (knowing no errors can occur)
Sometimes, doing all the error checking at the top is not feasible or
sensible. AISI output buffering is an ideal way to read inputs (files
and tables) once and produce the body of the output at the same time. If
there are no errors then the buffer contents can be sent. What's wrong
with that?
>> A fail() function which will ob_end_clean and then render a suitable
>> failure HTML page.
>>
>
> See above.
>
>> Some sort of debugging functions which will work with output buffer
>> capture to generate sensible debug output.
>>
>
> See above.
>
>> Is there anything else that should be present at the top of a piece of
>> code?
>>
>
> Only what is necessary.
>
>> Given the fact that some of the above may vary between environments such
>> as test and production is it feasible to pull in something like the
>> above with
>>
>> require_once("preamble_code.php");
>>
>
> I include my own class files and files with database userid/passwords
> (which are stored outside of the DOCUMENT_ROOT). I don't have a
> standard preamble.
>
>> I have code such as the above at the moment but for various reasons it
>> is not completely satisfactory. I wondered if people who were more
>> familiar with PHP had come up with a better approach.
>>
>
> Probably because it's a bad idea.
I don't think it's a bad idea to have some initial setup code, for the
reasons mentioned above. My main problem is currently having to
replicate too much at the top of each program.
How about the following as an approach?
require("code_preamble_XXX"); (Where XXX is dev or prod)
and then call certain functions from the code_preamble with parameters
to customise their effects as necessary.
>> If some of the above can be parameterised might it even be possible to
>> come up with a universal module that can be pulled in with require_once
>> (and then the functions within it called with certain parameters)?
>>
>> James
>
> Just get rid of it. You'll be better off in the long run.
Thanks for the reply though I cannot (yet) see that omitting such a
preamble is better, for the reasons mentioned above.
James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-20 09:31 -0500 |
| Message-ID | <n56dvt$eht$1@jstuckle.eternal-september.org> |
| In reply to | #15927 |
On 12/20/2015 5:16 AM, James Harris wrote:
> On 19/12/2015 13:20, Jerry Stuckle wrote:
>> Please see below:
>>
>> On 12/19/2015 5:03 AM, James Harris wrote:
>>> In the interests of getting a consistent approach to developing PHP
>>> programs do you guys have any guidelines you follow and/or boilerplate
>>> you include when writing a new piece of PHP? For HTML output I mean
>>> things like the following.
>>>
>>> At the top of the code: setup such as error_reporting, ini_set etc and
>>> constant definitions.
>>>
>>
>> I do not change error_reporting or any ini_set. Terrible form. These
>> should be set correctly in your php.ini file. And constants, etc. are
>> set as necessary.
>
> Why is that "terrible form"? For one thing, I am not sure that I will
> always have update access to the php.ini file of a given hosting
> service, and I would rather the PHP program be portable. For another,
> could a given system not have two programs which need at least some
> different ini settings? For example, if developing a certain program I
> might begin it with
>
> error_reporting(E_ALL);
> ini_set("log_errors", "1");
> ini_set("display_errors", "1");
>
> That program could exist alongside others that were already developed
> and which did not need such debugging.
>
You should NEVER be developing on a production machine. You have a
development machine with the php.ini file set to display all errors.
Your production machine does not show any errors.
And exactly what different php.ini settings should you require on a
production machine? And as for not having access to php.ini - any
decent hosting company knows to properly set up their php (and web
server) installation. If they don't, go somewhere else!
>>> Use of ob_start before the code generates 'normal' output so that the
>>> program can present custom error information if something goes wrong.
>>>
>>
>> Needing to use ob_start is needless overhead and indicates poor design
>> of your code.
>
> What you say suggests either that it's OK for errors to happen midway
> through the code (after some of the page has been produced) or that the
> code has the form:
>
> 1. Do all error checking
> 2. Produce the web page (knowing no errors can occur)
>
If there is an error, handle it! There should never be an error in
production code which terminates PHP processing. Other errors should be
handled in a sensible manner.
> Sometimes, doing all the error checking at the top is not feasible or
> sensible. AISI output buffering is an ideal way to read inputs (files
> and tables) once and produce the body of the output at the same time. If
> there are no errors then the buffer contents can be sent. What's wrong
> with that?
>
It's a waste of system resources, slows down both server and client
processing and shows a lack of understanding of good programming practices.
>>> A fail() function which will ob_end_clean and then render a suitable
>>> failure HTML page.
>>>
>>
>> See above.
>>
>>> Some sort of debugging functions which will work with output buffer
>>> capture to generate sensible debug output.
>>>
>>
>> See above.
>>
>>> Is there anything else that should be present at the top of a piece of
>>> code?
>>>
>>
>> Only what is necessary.
>>
>>> Given the fact that some of the above may vary between environments such
>>> as test and production is it feasible to pull in something like the
>>> above with
>>>
>>> require_once("preamble_code.php");
>>>
>>
>> I include my own class files and files with database userid/passwords
>> (which are stored outside of the DOCUMENT_ROOT). I don't have a
>> standard preamble.
>>
>>> I have code such as the above at the moment but for various reasons it
>>> is not completely satisfactory. I wondered if people who were more
>>> familiar with PHP had come up with a better approach.
>>>
>>
>> Probably because it's a bad idea.
>
> I don't think it's a bad idea to have some initial setup code, for the
> reasons mentioned above. My main problem is currently having to
> replicate too much at the top of each program.
>
That's because you're not using good programming practices. What do you
have in the preamble, anyway?
> How about the following as an approach?
>
> require("code_preamble_XXX"); (Where XXX is dev or prod)
>
> and then call certain functions from the code_preamble with parameters
> to customise their effects as necessary.
>
Again, exactly what are you doing in the preamble that's required on
every page?
>>> If some of the above can be parameterised might it even be possible to
>>> come up with a universal module that can be pulled in with require_once
>>> (and then the functions within it called with certain parameters)?
>>>
>>> James
>>
>> Just get rid of it. You'll be better off in the long run.
>
> Thanks for the reply though I cannot (yet) see that omitting such a
> preamble is better, for the reasons mentioned above.
>
> James
>
>
I told you what I put in such a preamble - nothing other than common
classes which I've developed and userids/passwords. And I haven't, for
around 15 years of PHP programming and thousands of PHP pages. I don't
need them because I use good programing practices instead of snarky
work-arounds which cause more problems in the long run.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-12-20 17:11 +0000 |
| Message-ID | <n56nbb$ide$1@dont-email.me> |
| In reply to | #15928 |
On 20/12/2015 14:31, Jerry Stuckle wrote:
> On 12/20/2015 5:16 AM, James Harris wrote:
>> On 19/12/2015 13:20, Jerry Stuckle wrote:
>>> Please see below:
>>>
>>> On 12/19/2015 5:03 AM, James Harris wrote:
>>>> In the interests of getting a consistent approach to developing PHP
>>>> programs do you guys have any guidelines you follow and/or boilerplate
>>>> you include when writing a new piece of PHP? For HTML output I mean
>>>> things like the following.
>>>>
>>>> At the top of the code: setup such as error_reporting, ini_set etc and
>>>> constant definitions.
>>>>
>>>
>>> I do not change error_reporting or any ini_set. Terrible form. These
>>> should be set correctly in your php.ini file. And constants, etc. are
>>> set as necessary.
>>
>> Why is that "terrible form"? For one thing, I am not sure that I will
>> always have update access to the php.ini file of a given hosting
>> service, and I would rather the PHP program be portable. For another,
>> could a given system not have two programs which need at least some
>> different ini settings? For example, if developing a certain program I
>> might begin it with
>>
>> error_reporting(E_ALL);
>> ini_set("log_errors", "1");
>> ini_set("display_errors", "1");
>>
>> That program could exist alongside others that were already developed
>> and which did not need such debugging.
>>
>
> You should NEVER be developing on a production machine.
That's another issue (which it might be interesting to discuss) but it
is not what I was talking about.
> You have a
> development machine with the php.ini file set to display all errors.
> Your production machine does not show any errors.
As mentioned before, I cannot guarantee the content of php.ini on all
hosts where my code might run so it makes sense to me to ensure certain
settings (if that's really the effect that ini_set has...?).
What is your objection to using ini_set at the top of a piece of code?
Wouldn't it allow a programmer to insulate a program from at least some
unwanted php.ini content? If the php.ini already has some of the
settings that we want then there is no loss, AIUI.
> And exactly what different php.ini settings should you require on a
> production machine? And as for not having access to php.ini - any
> decent hosting company knows to properly set up their php (and web
> server) installation. If they don't, go somewhere else!
We've discussed stuff like this before. Life is not always so cut and
dried as you might like it to be. If someone wants you to work on an
existing system and you don't like something about it do you tell the
client to move to a new provider or you won't touch the code? Or, if you
are doing a favour for a friend do you tell that friend you won't help
unless a new provider is chosen?
>>>> Use of ob_start before the code generates 'normal' output so that the
>>>> program can present custom error information if something goes wrong.
>>>>
>>>
>>> Needing to use ob_start is needless overhead and indicates poor design
>>> of your code.
>>
>> What you say suggests either that it's OK for errors to happen midway
>> through the code (after some of the page has been produced) or that the
>> code has the form:
>>
>> 1. Do all error checking
>> 2. Produce the web page (knowing no errors can occur)
>>
>
> If there is an error, handle it! There should never be an error in
> production code which terminates PHP processing. Other errors should be
> handled in a sensible manner.
Maybe I didn't explain that clearly enough. I meant that if you want the
output HTML to differ if there are runtime errors (as I do in some
cases) you either have to go through the processing steps twice (which
is unreliable for things like database contents where tables can be
updated between the first read and the second) or you have to hold on to
some of the output until you have checked for all possible errors.
Since you recommended against output buffering I have been looking at a
different way to handle it. I now store any relevant info as it is read.
Once everything has checked out as OK and there are no errors I then go
and generate the HTML from the stored info. It has a similar effect as
output buffering but is probably a better way to work.
A simple example is the page title. Consider emitting
<title>T</title>
There is to be a certain title, T, if everything is normal and a
different title if something goes wrong. I cannot produce that line or
anything after it (which essentially includes all the page content)
until I know whether there are any errors or not. (Such errors are not
from bugs but from runtime issues such as absence of resources.)
Since you object to what I am doing what would you do for such a title
problem?
...
>>>> I have code such as the above at the moment but for various reasons it
>>>> is not completely satisfactory. I wondered if people who were more
>>>> familiar with PHP had come up with a better approach.
>>>>
>>>
>>> Probably because it's a bad idea.
>>
>> I don't think it's a bad idea to have some initial setup code, for the
>> reasons mentioned above. My main problem is currently having to
>> replicate too much at the top of each program.
>>
>
> That's because you're not using good programming practices.
In your opinion, you mean. In fact, I am probably writing code that is
more robust than you are used to.... :-)
> What do you
> have in the preamble, anyway?
At the moment, aside from the ini_sets above, basically the same as you
tell me you have, below. If you don't like what I have then you are also
criticising yourself.
>> How about the following as an approach?
>>
>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>
>> and then call certain functions from the code_preamble with parameters
>> to customise their effects as necessary.
>>
>
> Again, exactly what are you doing in the preamble that's required on
> every page?
This is not about page content such as headers, sidebars, footers etc.
That's a separate issue. This is purely about setup for PHP programming.
...
> I told you what I put in such a preamble - nothing other than common
> classes which I've developed and userids/passwords. And I haven't, for
> around 15 years of PHP programming and thousands of PHP pages. I don't
> need them because I use good programing practices instead of snarky
> work-arounds which cause more problems in the long run.
It sounds like you do what you are complaining about me suggesting...!
James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-20 16:42 -0500 |
| Message-ID | <n5777c$ju2$1@jstuckle.eternal-september.org> |
| In reply to | #15929 |
On 12/20/2015 12:11 PM, James Harris wrote:
> On 20/12/2015 14:31, Jerry Stuckle wrote:
>> On 12/20/2015 5:16 AM, James Harris wrote:
>>> On 19/12/2015 13:20, Jerry Stuckle wrote:
>>>> Please see below:
>>>>
>>>> On 12/19/2015 5:03 AM, James Harris wrote:
>>>>> In the interests of getting a consistent approach to developing PHP
>>>>> programs do you guys have any guidelines you follow and/or boilerplate
>>>>> you include when writing a new piece of PHP? For HTML output I mean
>>>>> things like the following.
>>>>>
>>>>> At the top of the code: setup such as error_reporting, ini_set etc and
>>>>> constant definitions.
>>>>>
>>>>
>>>> I do not change error_reporting or any ini_set. Terrible form. These
>>>> should be set correctly in your php.ini file. And constants, etc. are
>>>> set as necessary.
>>>
>>> Why is that "terrible form"? For one thing, I am not sure that I will
>>> always have update access to the php.ini file of a given hosting
>>> service, and I would rather the PHP program be portable. For another,
>>> could a given system not have two programs which need at least some
>>> different ini settings? For example, if developing a certain program I
>>> might begin it with
>>>
>>> error_reporting(E_ALL);
>>> ini_set("log_errors", "1");
>>> ini_set("display_errors", "1");
>>>
>>> That program could exist alongside others that were already developed
>>> and which did not need such debugging.
>>>
>>
>> You should NEVER be developing on a production machine.
>
> That's another issue (which it might be interesting to discuss) but it
> is not what I was talking about.
>
Then there is no reason to change the ini settings.
>> You have a
>> development machine with the php.ini file set to display all errors.
>> Your production machine does not show any errors.
>
> As mentioned before, I cannot guarantee the content of php.ini on all
> hosts where my code might run so it makes sense to me to ensure certain
> settings (if that's really the effect that ini_set has...?).
>
It's not your responsibility to determine what other peoples' php.ini
files are set to.
> What is your objection to using ini_set at the top of a piece of code?
> Wouldn't it allow a programmer to insulate a program from at least some
> unwanted php.ini content? If the php.ini already has some of the
> settings that we want then there is no loss, AIUI.
>
Because it is not your machine you are running on. If the customer
wants to change the settings to something else, that's his/her privilege
- and responsibility. It is not your responsibility to change those -
even for your code.
>> And exactly what different php.ini settings should you require on a
>> production machine? And as for not having access to php.ini - any
>> decent hosting company knows to properly set up their php (and web
>> server) installation. If they don't, go somewhere else!
>
> We've discussed stuff like this before. Life is not always so cut and
> dried as you might like it to be. If someone wants you to work on an
> existing system and you don't like something about it do you tell the
> client to move to a new provider or you won't touch the code? Or, if you
> are doing a favour for a friend do you tell that friend you won't help
> unless a new provider is chosen?
>
That's right. If the provider isn't smart enough to provide a sensible
php.ini file, I have no idea what else is wrong with their site -
including security. And yes, I won't be responsible for code running on
such a provider - which also means I won't work on it. Has it cost me
in the past? Never in the long run.
And I don't work for friends. I work for clients. If someone wants my
time, they pay for it.
>>>>> Use of ob_start before the code generates 'normal' output so that the
>>>>> program can present custom error information if something goes wrong.
>>>>>
>>>>
>>>> Needing to use ob_start is needless overhead and indicates poor design
>>>> of your code.
>>>
>>> What you say suggests either that it's OK for errors to happen midway
>>> through the code (after some of the page has been produced) or that the
>>> code has the form:
>>>
>>> 1. Do all error checking
>>> 2. Produce the web page (knowing no errors can occur)
>>>
>>
>> If there is an error, handle it! There should never be an error in
>> production code which terminates PHP processing. Other errors should be
>> handled in a sensible manner.
>
> Maybe I didn't explain that clearly enough. I meant that if you want the
> output HTML to differ if there are runtime errors (as I do in some
> cases) you either have to go through the processing steps twice (which
> is unreliable for things like database contents where tables can be
> updated between the first read and the second) or you have to hold on to
> some of the output until you have checked for all possible errors.
>
As I said - you handle it appropriately. I never go through the steps
twice - but I still put out the appropriate errors when necessary. It's
all in how to properly structure your code - which includes not using
ob_start().
> Since you recommended against output buffering I have been looking at a
> different way to handle it. I now store any relevant info as it is read.
> Once everything has checked out as OK and there are no errors I then go
> and generate the HTML from the stored info. It has a similar effect as
> output buffering but is probably a better way to work.
>
Yes, that's one way of doing it. But I seldom have to issue more than
one database query per page, and I display the results as I process the
data. I know if there's an error on the query.
If you're having to make several database calls on a single page,
chances are your design (database or page) is incorrect.
> A simple example is the page title. Consider emitting
>
> <title>T</title>
>
> There is to be a certain title, T, if everything is normal and a
> different title if something goes wrong. I cannot produce that line or
> anything after it (which essentially includes all the page content)
> until I know whether there are any errors or not. (Such errors are not
> from bugs but from runtime issues such as absence of resources.)
>
> Since you object to what I am doing what would you do for such a title
> problem?
>
Exactly what errors are you talking about?
> ...
>
>>>>> I have code such as the above at the moment but for various reasons it
>>>>> is not completely satisfactory. I wondered if people who were more
>>>>> familiar with PHP had come up with a better approach.
>>>>>
>>>>
>>>> Probably because it's a bad idea.
>>>
>>> I don't think it's a bad idea to have some initial setup code, for the
>>> reasons mentioned above. My main problem is currently having to
>>> replicate too much at the top of each program.
>>>
>>
>> That's because you're not using good programming practices.
>
> In your opinion, you mean. In fact, I am probably writing code that is
> more robust than you are used to.... :-)
>
After 47 years of writing code in close to 20 languages (including 13
years with IBM), I doubt it very much.
>> What do you
>> have in the preamble, anyway?
>
> At the moment, aside from the ini_sets above, basically the same as you
> tell me you have, below. If you don't like what I have then you are also
> criticising yourself.
>
No, I'm telling you I don't have a preamble. I include classes I've
developed myself, where necessary. I include userid's and passwords to
databases. But I don't include any ini_set(), ob_start() or any other
garbage code.
>>> How about the following as an approach?
>>>
>>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>>
>>> and then call certain functions from the code_preamble with parameters
>>> to customise their effects as necessary.
>>>
>>
>> Again, exactly what are you doing in the preamble that's required on
>> every page?
>
> This is not about page content such as headers, sidebars, footers etc.
> That's a separate issue. This is purely about setup for PHP programming.
>
You're not answering my question.
> ...
>
>> I told you what I put in such a preamble - nothing other than common
>> classes which I've developed and userids/passwords. And I haven't, for
>> around 15 years of PHP programming and thousands of PHP pages. I don't
>> need them because I use good programing practices instead of snarky
>> work-arounds which cause more problems in the long run.
>
> It sounds like you do what you are complaining about me suggesting...!
>
> James
>
Not at all. Common classes are reusable code (i.e. database access
classes). Userids and passwords should NEVER be in a file that's in the
server's DOCUMENT_ROOT.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-12-25 15:56 +0000 |
| Message-ID | <n5jopt$ou8$1@dont-email.me> |
| In reply to | #15930 |
On 20/12/2015 21:42, Jerry Stuckle wrote:
> On 12/20/2015 12:11 PM, James Harris wrote:
>> On 20/12/2015 14:31, Jerry Stuckle wrote:
>>> On 12/20/2015 5:16 AM, James Harris wrote:
>>>> On 19/12/2015 13:20, Jerry Stuckle wrote:
>>>>> Please see below:
>>>>>
>>>>> On 12/19/2015 5:03 AM, James Harris wrote:
>>>>>> In the interests of getting a consistent approach to developing PHP
>>>>>> programs do you guys have any guidelines you follow and/or boilerplate
>>>>>> you include when writing a new piece of PHP? For HTML output I mean
>>>>>> things like the following.
>>>>>>
>>>>>> At the top of the code: setup such as error_reporting, ini_set etc and
>>>>>> constant definitions.
>>>>>>
>>>>>
>>>>> I do not change error_reporting or any ini_set. Terrible form. These
>>>>> should be set correctly in your php.ini file. And constants, etc. are
>>>>> set as necessary.
>>>>
>>>> Why is that "terrible form"? For one thing, I am not sure that I will
>>>> always have update access to the php.ini file of a given hosting
>>>> service, and I would rather the PHP program be portable. For another,
>>>> could a given system not have two programs which need at least some
>>>> different ini settings? For example, if developing a certain program I
>>>> might begin it with
>>>>
>>>> error_reporting(E_ALL);
>>>> ini_set("log_errors", "1");
>>>> ini_set("display_errors", "1");
>>>>
>>>> That program could exist alongside others that were already developed
>>>> and which did not need such debugging.
>>>>
>>>
>>> You should NEVER be developing on a production machine.
>>
>> That's another issue (which it might be interesting to discuss) but it
>> is not what I was talking about.
>>
>
> Then there is no reason to change the ini settings.
That is a non sequitur.
>>> You have a
>>> development machine with the php.ini file set to display all errors.
>>> Your production machine does not show any errors.
>>
>> As mentioned before, I cannot guarantee the content of php.ini on all
>> hosts where my code might run so it makes sense to me to ensure certain
>> settings (if that's really the effect that ini_set has...?).
>>
>
> It's not your responsibility to determine what other peoples' php.ini
> files are set to.
I did not propose setting someone else's php.ini, only overriding select
few values if needed for a specific program so that that program can
execute with certain guarantees. You are used to controlling the php.ini
file which could have led you to always trusting every single one of its
settings.
...
>> A simple example is the page title. Consider emitting
>>
>> <title>T</title>
>>
>> There is to be a certain title, T, if everything is normal and a
>> different title if something goes wrong. I cannot produce that line or
>> anything after it (which essentially includes all the page content)
>> until I know whether there are any errors or not. (Such errors are not
>> from bugs but from runtime issues such as absence of resources.)
>>
>> Since you object to what I am doing what would you do for such a title
>> problem?
>>
>
> Exactly what errors are you talking about?
That would depend on the needs of a specific program. Remember, I was
asking about an approach that would be valid for general PHP programming
rather than something specific. Basically, such errors would be any
which meant that the page designer wanted to result in a different
title. Such errors would include any resources that the page needed
which might be external to the PHP program.
>>>>>> I have code such as the above at the moment but for various reasons it
>>>>>> is not completely satisfactory. I wondered if people who were more
>>>>>> familiar with PHP had come up with a better approach.
>>>>>>
>>>>>
>>>>> Probably because it's a bad idea.
>>>>
>>>> I don't think it's a bad idea to have some initial setup code, for the
>>>> reasons mentioned above. My main problem is currently having to
>>>> replicate too much at the top of each program.
>>>>
>>>
>>> That's because you're not using good programming practices.
>>
>> In your opinion, you mean. In fact, I am probably writing code that is
>> more robust than you are used to.... :-)
>>
>
> After 47 years of writing code in close to 20 languages (including 13
> years with IBM), I doubt it very much.
Well, my comment was somewhat tongue-in-cheek but time programming
doesn't correlate with attitude to robustness. That is especially true
for you as you are used to completely controlling the environment in
which your PHP scripts run.
>>> What do you
>>> have in the preamble, anyway?
>>
>> At the moment, aside from the ini_sets above, basically the same as you
>> tell me you have, below. If you don't like what I have then you are also
>> criticising yourself.
>>
>
> No, I'm telling you I don't have a preamble. I include classes I've
> developed myself, where necessary. I include userid's and passwords to
> databases. But I don't include any ini_set(), ob_start() or any other
> garbage code.
I would call any standard includes a preamble.
>>>> How about the following as an approach?
>>>>
>>>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>>>
>>>> and then call certain functions from the code_preamble with parameters
>>>> to customise their effects as necessary.
>>>>
>>>
>>> Again, exactly what are you doing in the preamble that's required on
>>> every page?
>>
>> This is not about page content such as headers, sidebars, footers etc.
>> That's a separate issue. This is purely about setup for PHP programming.
>>
>
> You're not answering my question.
Well, this thread was there to ask for specifics but it could include
environment settings, common utility routines, debugging routines if
developing, common classes, database access parameters etc.
>>> I told you what I put in such a preamble - nothing other than common
>>> classes which I've developed and userids/passwords. And I haven't, for
>>> around 15 years of PHP programming and thousands of PHP pages. I don't
>>> need them because I use good programing practices instead of snarky
>>> work-arounds which cause more problems in the long run.
>>
>> It sounds like you do what you are complaining about me suggesting...!
>>
>> James
>>
>
> Not at all. Common classes are reusable code (i.e. database access
> classes). Userids and passwords should NEVER be in a file that's in the
> server's DOCUMENT_ROOT.
I did not say that the stuff included had to be under the DOCUMENT_ROOT.
James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-25 11:23 -0500 |
| Message-ID | <n5jqdp$u90$1@jstuckle.eternal-september.org> |
| In reply to | #15986 |
On 12/25/2015 10:56 AM, James Harris wrote:
> On 20/12/2015 21:42, Jerry Stuckle wrote:
>> On 12/20/2015 12:11 PM, James Harris wrote:
>>> On 20/12/2015 14:31, Jerry Stuckle wrote:
>>>> On 12/20/2015 5:16 AM, James Harris wrote:
>>>>> On 19/12/2015 13:20, Jerry Stuckle wrote:
>>>>>> Please see below:
>>>>>>
>>>>>> On 12/19/2015 5:03 AM, James Harris wrote:
>>>>>>> In the interests of getting a consistent approach to developing PHP
>>>>>>> programs do you guys have any guidelines you follow and/or
>>>>>>> boilerplate
>>>>>>> you include when writing a new piece of PHP? For HTML output I mean
>>>>>>> things like the following.
>>>>>>>
>>>>>>> At the top of the code: setup such as error_reporting, ini_set
>>>>>>> etc and
>>>>>>> constant definitions.
>>>>>>>
>>>>>>
>>>>>> I do not change error_reporting or any ini_set. Terrible form.
>>>>>> These
>>>>>> should be set correctly in your php.ini file. And constants, etc.
>>>>>> are
>>>>>> set as necessary.
>>>>>
>>>>> Why is that "terrible form"? For one thing, I am not sure that I will
>>>>> always have update access to the php.ini file of a given hosting
>>>>> service, and I would rather the PHP program be portable. For another,
>>>>> could a given system not have two programs which need at least some
>>>>> different ini settings? For example, if developing a certain program I
>>>>> might begin it with
>>>>>
>>>>> error_reporting(E_ALL);
>>>>> ini_set("log_errors", "1");
>>>>> ini_set("display_errors", "1");
>>>>>
>>>>> That program could exist alongside others that were already developed
>>>>> and which did not need such debugging.
>>>>>
>>>>
>>>> You should NEVER be developing on a production machine.
>>>
>>> That's another issue (which it might be interesting to discuss) but it
>>> is not what I was talking about.
>>>
>>
>> Then there is no reason to change the ini settings.
>
> That is a non sequitur.
>
>>>> You have a
>>>> development machine with the php.ini file set to display all errors.
>>>> Your production machine does not show any errors.
>>>
>>> As mentioned before, I cannot guarantee the content of php.ini on all
>>> hosts where my code might run so it makes sense to me to ensure certain
>>> settings (if that's really the effect that ini_set has...?).
>>>
>>
>> It's not your responsibility to determine what other peoples' php.ini
>> files are set to.
>
> I did not propose setting someone else's php.ini, only overriding select
> few values if needed for a specific program so that that program can
> execute with certain guarantees. You are used to controlling the php.ini
> file which could have led you to always trusting every single one of its
> settings.
>
Which is exactly what you should NOT do. I didn't say you should change
their php.ini. I said you shouldn't override the settings they want.
It is their system, not yours.
> ...
>
>>> A simple example is the page title. Consider emitting
>>>
>>> <title>T</title>
>>>
>>> There is to be a certain title, T, if everything is normal and a
>>> different title if something goes wrong. I cannot produce that line or
>>> anything after it (which essentially includes all the page content)
>>> until I know whether there are any errors or not. (Such errors are not
>>> from bugs but from runtime issues such as absence of resources.)
>>>
>>> Since you object to what I am doing what would you do for such a title
>>> problem?
>>>
>>
>> Exactly what errors are you talking about?
>
> That would depend on the needs of a specific program. Remember, I was
> asking about an approach that would be valid for general PHP programming
> rather than something specific. Basically, such errors would be any
> which meant that the page designer wanted to result in a different
> title. Such errors would include any resources that the page needed
> which might be external to the PHP program.
>
Not overriding any php.ini settings is valid for general PHP
programming. If you want to change things, the code your page
appropriately.
>>>>>>> I have code such as the above at the moment but for various
>>>>>>> reasons it
>>>>>>> is not completely satisfactory. I wondered if people who were more
>>>>>>> familiar with PHP had come up with a better approach.
>>>>>>>
>>>>>>
>>>>>> Probably because it's a bad idea.
>>>>>
>>>>> I don't think it's a bad idea to have some initial setup code, for the
>>>>> reasons mentioned above. My main problem is currently having to
>>>>> replicate too much at the top of each program.
>>>>>
>>>>
>>>> That's because you're not using good programming practices.
>>>
>>> In your opinion, you mean. In fact, I am probably writing code that is
>>> more robust than you are used to.... :-)
>>>
>>
>> After 47 years of writing code in close to 20 languages (including 13
>> years with IBM), I doubt it very much.
>
> Well, my comment was somewhat tongue-in-cheek but time programming
> doesn't correlate with attitude to robustness. That is especially true
> for you as you are used to completely controlling the environment in
> which your PHP scripts run.
>
The point is - you are NOT writing robust code. In fact, your code is
less robust than what most people write, because they don't need to
override php.ini settings.
>>>> What do you
>>>> have in the preamble, anyway?
>>>
>>> At the moment, aside from the ini_sets above, basically the same as you
>>> tell me you have, below. If you don't like what I have then you are also
>>> criticising yourself.
>>>
>>
>> No, I'm telling you I don't have a preamble. I include classes I've
>> developed myself, where necessary. I include userid's and passwords to
>> databases. But I don't include any ini_set(), ob_start() or any other
>> garbage code.
>
> I would call any standard includes a preamble.
>
I didn't say I had a "standard include". I said I include classes that
and userids/passwords that *are needed*. Each page has different needs,
and generally includes different classes.
A class file is *not* a "preamble". Neither is a file containing
userids and passwords.
>>>>> How about the following as an approach?
>>>>>
>>>>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>>>>
>>>>> and then call certain functions from the code_preamble with parameters
>>>>> to customise their effects as necessary.
>>>>>
>>>>
>>>> Again, exactly what are you doing in the preamble that's required on
>>>> every page?
>>>
>>> This is not about page content such as headers, sidebars, footers etc.
>>> That's a separate issue. This is purely about setup for PHP programming.
>>>
>>
>> You're not answering my question.
>
> Well, this thread was there to ask for specifics but it could include
> environment settings, common utility routines, debugging routines if
> developing, common classes, database access parameters etc.
>
I have answered your question multiple times. But you aren't listening.
Include what the script needs - nothing more, nothing less. And don't
change the user's php.ini settings.
>>>> I told you what I put in such a preamble - nothing other than common
>>>> classes which I've developed and userids/passwords. And I haven't, for
>>>> around 15 years of PHP programming and thousands of PHP pages. I don't
>>>> need them because I use good programing practices instead of snarky
>>>> work-arounds which cause more problems in the long run.
>>>
>>> It sounds like you do what you are complaining about me suggesting...!
>>>
>>> James
>>>
>>
>> Not at all. Common classes are reusable code (i.e. database access
>> classes). Userids and passwords should NEVER be in a file that's in the
>> server's DOCUMENT_ROOT.
>
> I did not say that the stuff included had to be under the DOCUMENT_ROOT.
>
> James
>
*I* said the userids and passwords should *not* be under the
DOCUMENT_ROOT. Other files containing non-security related information
can be pretty much anywhere.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2015-12-26 10:09 +0000 |
| Message-ID | <n5losu$711$1@dont-email.me> |
| In reply to | #15987 |
On 25/12/2015 16:23, Jerry Stuckle wrote:
> On 12/25/2015 10:56 AM, James Harris wrote:
>> On 20/12/2015 21:42, Jerry Stuckle wrote:
...
There are at least two aspects to this and it is important to
distinguish them.
1. The settings in each php.ini file
2. Resources which are external to the PHP program
IMO it should be possible to write one program and have it work in many
different environments, each of which has its own php.ini file.
The program should also be robust enough correctly to handle the absence
or loss of any external resources.
I mention that distinction at the start of this reply in case you are
thinking just about the ini file.
>>> It's not your responsibility to determine what other peoples'
>>> php.ini files are set to.
>>
>> I did not propose setting someone else's php.ini, only overriding
>> select few values if needed for a specific program so that that
>> program can execute with certain guarantees. You are used to
>> controlling the php.ini file which could have led you to always
>> trusting every single one of its settings.
>>
>
> Which is exactly what you should NOT do. I didn't say you should
> change their php.ini. I said you shouldn't override the settings
> they want. It is their system, not yours.
Are you saying that of the 500 or so currently defined php.ini settings
there are none that you would ever want to override, not even one? Do
you really know the 500+ settings that well? I don't.
And what about php.ini settings that might be added in future versions
of PHP? Are you saying you know now that you would never want to
override any of them, even without yet knowing what they will be? That
seems unreasonable to me.
More importantly, consider that you want your PHP program to run,
completely unchanged, in many different environments. They could be your
test environment(s) and many different potential production
environments. Don't get me wrong. I think I would trust the vast
majority of the ini file settings of those environments. But without
knowing what they all are I am not prepared to give them carte-blanche -
which is why I was asking about overriding certain such settings.
>>>> A simple example is the page title. Consider emitting
>>>>
>>>> <title>T</title>
>>>>
>>>> There is to be a certain title, T, if everything is normal and
>>>> a different title if something goes wrong. I cannot produce
>>>> that line or anything after it (which essentially includes all
>>>> the page content) until I know whether there are any errors or
>>>> not. (Such errors are not from bugs but from runtime issues
>>>> such as absence of resources.)
>>>>
>>>> Since you object to what I am doing what would you do for such
>>>> a title problem?
>>>>
>>>
>>> Exactly what errors are you talking about?
>>
>> That would depend on the needs of a specific program. Remember, I
>> was asking about an approach that would be valid for general PHP
>> programming rather than something specific. Basically, such errors
>> would be any which meant that the page designer wanted to result in
>> a different title. Such errors would include any resources that the
>> page needed which might be external to the PHP program.
>>
>
> Not overriding any php.ini settings is valid for general PHP
> programming. If you want to change things, the code your page
> appropriately.
You may be mixing two things up. The ini file was discussed above. This
part of the discussion is not about ini file settings but about being
able to set a page's title only once certain resources (such as the
contents of files and databases) are known to be present and correct.
You didn't answer the question which was: as you don't like my idea of
storing or buffering data before generating the title, what would you do
so that the title can differ depending on what resources are available?
I am aware that the title could be changed in JavaScript but that would
only work in browsers where JavaScript is enabled. So the only
guaranteed approach I can see is to hold on to the critical data until
all checks have been completed.
>>>>>>>> I have code such as the above at the moment but for
>>>>>>>> various reasons it is not completely satisfactory. I
>>>>>>>> wondered if people who were more familiar with PHP had
>>>>>>>> come up with a better approach.
>>>>>>>>
>>>>>>>
>>>>>>> Probably because it's a bad idea.
>>>>>>
>>>>>> I don't think it's a bad idea to have some initial setup
>>>>>> code, for the reasons mentioned above. My main problem is
>>>>>> currently having to replicate too much at the top of each
>>>>>> program.
>>>>>>
>>>>>
>>>>> That's because you're not using good programming practices.
>>>>
>>>> In your opinion, you mean. In fact, I am probably writing code
>>>> that is more robust than you are used to.... :-)
>>>>
>>>
>>> After 47 years of writing code in close to 20 languages
>>> (including 13 years with IBM), I doubt it very much.
>>
>> Well, my comment was somewhat tongue-in-cheek but time programming
>> doesn't correlate with attitude to robustness. That is especially
>> true for you as you are used to completely controlling the
>> environment in which your PHP scripts run.
>>
>
> The point is - you are NOT writing robust code. In fact, your code
> is less robust than what most people write, because they don't need
> to override php.ini settings.
Nonsense! The whole point of this discussion is about making code robust.
I spoke about overriding certain ini settings so that the code would be
robust enough to handle different environments.
I spoke about error checking before generating output so that the code
would be robust enough to cope with absence or loss of external resources.
You keep talking about php.ini settings but that is discussed at the
top. The main part of this discussion, including the part above, is more
about checking that all necessary resources are present before
generating a "success page" AND ensuring that data from those resources
are still available when we come to generate the contents of the page.
The title issue, above, is an excellent example showing that we cannot
always start generating HTML until we have carried out checks and cached
necessary data. From what you have said, you expect a page to depend on
only one resource (if it's present you start to generate output) and if
that resource fails partway through you say it is such a remote chance
that it's not worth programming for. I would call your assumptions LESS
robust than mine.
>>>>> What do you have in the preamble, anyway?
>>>>
>>>> At the moment, aside from the ini_sets above, basically the
>>>> same as you tell me you have, below. If you don't like what I
>>>> have then you are also criticising yourself.
>>>>
>>>
>>> No, I'm telling you I don't have a preamble. I include classes
>>> I've developed myself, where necessary. I include userid's and
>>> passwords to databases. But I don't include any ini_set(),
>>> ob_start() or any other garbage code.
>>
>> I would call any standard includes a preamble.
>>
>
> I didn't say I had a "standard include". I said I include classes
> that and userids/passwords that *are needed*. Each page has
> different needs, and generally includes different classes.
>
> A class file is *not* a "preamble". Neither is a file containing
> userids and passwords.
Well, I would regard a common statement which includes a class file to
be a preamble, or part of one. I was asking about something to put at
the top of every PHP file. That could be a single include, if that would do.
>>>>>> How about the following as an approach?
>>>>>>
>>>>>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>>>>>
>>>>>> and then call certain functions from the code_preamble with
>>>>>> parameters to customise their effects as necessary.
>>>>>>
>>>>>
>>>>> Again, exactly what are you doing in the preamble that's
>>>>> required on every page?
>>>>
>>>> This is not about page content such as headers, sidebars,
>>>> footers etc. That's a separate issue. This is purely about
>>>> setup for PHP programming.
>>>>
>>>
>>> You're not answering my question.
>>
>> Well, this thread was there to ask for specifics but it could
>> include environment settings, common utility routines, debugging
>> routines if developing, common classes, database access parameters
>> etc.
>>
>
> I have answered your question multiple times. But you aren't
> listening.
There's a difference between listening and agreeing. I have listened to
what you have said. I even took on board your point about buffering and
have changed my approach. But I don't agree with everything you say.
That's a disagreement, not a failure to listen. The two are very
different things. Just because someone disagrees with you does not mean
he is not listening.
> Include what the script needs - nothing more, nothing
> less. And don't change the user's php.ini settings.
You keep answering about the php.ini file but that was dealt with at the
top.
Are you saying that there is NOTHING that you would include at the top
of every PHP file? Not even one include? What about a single include
which would pull in info or set settings relevant to the environment?
For example
require_once "current_env.php";
The idea of that would be to set settings relevant to the environment in
which the PHP script is to run. There might be many current_env.php
files, one for each environment, but all of them would set up things
needed for the including PHP program to run properly.
Any good?
>>>>> I told you what I put in such a preamble - nothing other than
>>>>> common classes which I've developed and userids/passwords.
>>>>> And I haven't, for around 15 years of PHP programming and
>>>>> thousands of PHP pages. I don't need them because I use good
>>>>> programing practices instead of snarky work-arounds which
>>>>> cause more problems in the long run.
>>>>
>>>> It sounds like you do what you are complaining about me
>>>> suggesting...!
>>>>
>>>> James
>>>>
>>>
>>> Not at all. Common classes are reusable code (i.e. database
>>> access classes). Userids and passwords should NEVER be in a file
>>> that's in the server's DOCUMENT_ROOT.
>>
>> I did not say that the stuff included had to be under the
>> DOCUMENT_ROOT.
>>
>> James
>>
>
> *I* said the userids and passwords should *not* be under the
> DOCUMENT_ROOT.
I know. As with elsewhere in this thread you seem to object to the
places where I expressed agreement with you.
James
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-26 09:33 -0500 |
| Message-ID | <n5m8b9$nrh$1@jstuckle.eternal-september.org> |
| In reply to | #15988 |
On 12/26/2015 5:09 AM, James Harris wrote:
> On 25/12/2015 16:23, Jerry Stuckle wrote:
>> On 12/25/2015 10:56 AM, James Harris wrote:
>>> On 20/12/2015 21:42, Jerry Stuckle wrote:
>
> ...
>
> There are at least two aspects to this and it is important to
> distinguish them.
>
> 1. The settings in each php.ini file
>
> 2. Resources which are external to the PHP program
>
> IMO it should be possible to write one program and have it work in many
> different environments, each of which has its own php.ini file.
>
> The program should also be robust enough correctly to handle the absence
> or loss of any external resources.
>
> I mention that distinction at the start of this reply in case you are
> thinking just about the ini file.
>
>>>> It's not your responsibility to determine what other peoples'
>>>> php.ini files are set to.
>>>
>>> I did not propose setting someone else's php.ini, only overriding
>>> select few values if needed for a specific program so that that
>>> program can execute with certain guarantees. You are used to
>>> controlling the php.ini file which could have led you to always
>>> trusting every single one of its settings.
>>>
>>
>> Which is exactly what you should NOT do. I didn't say you should
>> change their php.ini. I said you shouldn't override the settings
>> they want. It is their system, not yours.
>
> Are you saying that of the 500 or so currently defined php.ini settings
> there are none that you would ever want to override, not even one? Do
> you really know the 500+ settings that well? I don't.
>
That is correct. There are NONE I would override. If my scripts
required a specific setting, I would document that in the installation
instructions. But I've never had to do that because I write to
reasonable settings.
> And what about php.ini settings that might be added in future versions
> of PHP? Are you saying you know now that you would never want to
> override any of them, even without yet knowing what they will be? That
> seems unreasonable to me.
>
I can't say about future changes. I can only discuss what's there now.
The fact you're even bringing this up shows how desperate you are to
validate your position.
> More importantly, consider that you want your PHP program to run,
> completely unchanged, in many different environments. They could be your
> test environment(s) and many different potential production
> environments. Don't get me wrong. I think I would trust the vast
> majority of the ini file settings of those environments. But without
> knowing what they all are I am not prepared to give them carte-blanche -
> which is why I was asking about overriding certain such settings.
>
That is correct. My scripts run in many different environments. I have
both Windows and Linux test systems, and most of my scripts run on Linux.
But it is THEIR system - not YOURS. YOU are not in control of their
settings. The fact you even want to change the settings shows your
feelings of inadequacy as a programmer.
>>>>> A simple example is the page title. Consider emitting
>>>>>
>>>>> <title>T</title>
>>>>>
>>>>> There is to be a certain title, T, if everything is normal and
>>>>> a different title if something goes wrong. I cannot produce
>>>>> that line or anything after it (which essentially includes all
>>>>> the page content) until I know whether there are any errors or
>>>>> not. (Such errors are not from bugs but from runtime issues
>>>>> such as absence of resources.)
>>>>>
>>>>> Since you object to what I am doing what would you do for such
>>>>> a title problem?
>>>>>
>>>>
>>>> Exactly what errors are you talking about?
>>>
>>> That would depend on the needs of a specific program. Remember, I
>>> was asking about an approach that would be valid for general PHP
>>> programming rather than something specific. Basically, such errors
>>> would be any which meant that the page designer wanted to result in
>>> a different title. Such errors would include any resources that the
>>> page needed which might be external to the PHP program.
>>>
>>
>> Not overriding any php.ini settings is valid for general PHP
>> programming. If you want to change things, the code your page
>> appropriately.
>
> You may be mixing two things up. The ini file was discussed above. This
> part of the discussion is not about ini file settings but about being
> able to set a page's title only once certain resources (such as the
> contents of files and databases) are known to be present and correct.
> You didn't answer the question which was: as you don't like my idea of
> storing or buffering data before generating the title, what would you do
> so that the title can differ depending on what resources are available?
>
Which is fine. No, I don't like your idea of storing or buffering the
data. A properly written script doesn't need to do that. It's a
complete waste of system resources and slows down the rendering of your
page. The first is unfriendly to the system, the second unfriendly to
the user.
First of all, in what case do you need to change the title? You give
some indefinite comment "depending on what resources are available".
Once again, I've NEVER had to do that. If a resource is unavailable, I
state it is unavailable. No need to change the title.
If a resource is unavailable, I do it properly with a redirect to the
appropriate page. And I do it without buffering any data because I
structure my program properly.
I also don't worry about the case where a resource is available maybe
once in 10,000,000 times. I just display an error message and don't
bother with a redirect. There is no reason to complicate things for
occurrences which are so rare.
> I am aware that the title could be changed in JavaScript but that would
> only work in browsers where JavaScript is enabled. So the only
> guaranteed approach I can see is to hold on to the critical data until
> all checks have been completed.
>
No one runs without javascript nowadays. Too many sites require it.
But once again you shouldn't be doing it.
>>>>>>>>> I have code such as the above at the moment but for
>>>>>>>>> various reasons it is not completely satisfactory. I
>>>>>>>>> wondered if people who were more familiar with PHP had
>>>>>>>>> come up with a better approach.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Probably because it's a bad idea.
>>>>>>>
>>>>>>> I don't think it's a bad idea to have some initial setup
>>>>>>> code, for the reasons mentioned above. My main problem is
>>>>>>> currently having to replicate too much at the top of each
>>>>>>> program.
>>>>>>>
>>>>>>
>>>>>> That's because you're not using good programming practices.
>>>>>
>>>>> In your opinion, you mean. In fact, I am probably writing code
>>>>> that is more robust than you are used to.... :-)
>>>>>
>>>>
>>>> After 47 years of writing code in close to 20 languages
>>>> (including 13 years with IBM), I doubt it very much.
>>>
>>> Well, my comment was somewhat tongue-in-cheek but time programming
>>> doesn't correlate with attitude to robustness. That is especially
>>> true for you as you are used to completely controlling the
>>> environment in which your PHP scripts run.
>>>
>>
>> The point is - you are NOT writing robust code. In fact, your code
>> is less robust than what most people write, because they don't need
>> to override php.ini settings.
>
> Nonsense! The whole point of this discussion is about making code robust.
>
And you're not listening. You ask a question then argue with the answer.
> I spoke about overriding certain ini settings so that the code would be
> robust enough to handle different environments.
>
You're writing about changing the settings the USER wants. This is the
USER'S system, not YOURS.
> I spoke about error checking before generating output so that the code
> would be robust enough to cope with absence or loss of external resources.
>
So did I. But I'm not using system resources unnecessarily while doing it.
> You keep talking about php.ini settings but that is discussed at the
> top. The main part of this discussion, including the part above, is more
> about checking that all necessary resources are present before
> generating a "success page" AND ensuring that data from those resources
> are still available when we come to generate the contents of the page.
>
I have talked about that, also. But once again you argue with the answer.
> The title issue, above, is an excellent example showing that we cannot
> always start generating HTML until we have carried out checks and cached
> necessary data. From what you have said, you expect a page to depend on
> only one resource (if it's present you start to generate output) and if
> that resource fails partway through you say it is such a remote chance
> that it's not worth programming for. I would call your assumptions LESS
> robust than mine.
>
There is also a point where your error checking becomes more of a threat
than your script itself. You need to handle error conditions. But you
need to handle them *intelligently*.
>>>>>> What do you have in the preamble, anyway?
>>>>>
>>>>> At the moment, aside from the ini_sets above, basically the
>>>>> same as you tell me you have, below. If you don't like what I
>>>>> have then you are also criticising yourself.
>>>>>
>>>>
>>>> No, I'm telling you I don't have a preamble. I include classes
>>>> I've developed myself, where necessary. I include userid's and
>>>> passwords to databases. But I don't include any ini_set(),
>>>> ob_start() or any other garbage code.
>>>
>>> I would call any standard includes a preamble.
>>>
>>
>> I didn't say I had a "standard include". I said I include classes
>> that and userids/passwords that *are needed*. Each page has
>> different needs, and generally includes different classes.
>>
>> A class file is *not* a "preamble". Neither is a file containing
>> userids and passwords.
>
> Well, I would regard a common statement which includes a class file to
> be a preamble, or part of one. I was asking about something to put at
> the top of every PHP file. That could be a single include, if that would
> do.
>
It is not a preamble. I told you what I put at the top of every PHP
file - NOTHING. I include class files and userids and passwords where
necessary. Different pages have different needs, and therefore include
different files. One which does not do database access, for instance,
does not include database-related files. One which does require the
access includes the files. Some have no need for additional resources,
and include nothing.
>>>>>>> How about the following as an approach?
>>>>>>>
>>>>>>> require("code_preamble_XXX"); (Where XXX is dev or prod)
>>>>>>>
>>>>>>> and then call certain functions from the code_preamble with
>>>>>>> parameters to customise their effects as necessary.
>>>>>>>
>>>>>>
>>>>>> Again, exactly what are you doing in the preamble that's
>>>>>> required on every page?
>>>>>
>>>>> This is not about page content such as headers, sidebars,
>>>>> footers etc. That's a separate issue. This is purely about
>>>>> setup for PHP programming.
>>>>>
>>>>
>>>> You're not answering my question.
>>>
>>> Well, this thread was there to ask for specifics but it could
>>> include environment settings, common utility routines, debugging
>>> routines if developing, common classes, database access parameters
>>> etc.
>>>
>>
>> I have answered your question multiple times. But you aren't
>> listening.
>
> There's a difference between listening and agreeing. I have listened to
> what you have said. I even took on board your point about buffering and
> have changed my approach. But I don't agree with everything you say.
> That's a disagreement, not a failure to listen. The two are very
> different things. Just because someone disagrees with you does not mean
> he is not listening.
>
If you don't want the answer, don't ask the question. I have told you
how good PHP programmers do it. But you still want to argue.
>> Include what the script needs - nothing more, nothing
>> less. And don't change the user's php.ini settings.
>
> You keep answering about the php.ini file but that was dealt with at the
> top.
>
That is two different statements. But you're too caught up on the
php.ini file.
> Are you saying that there is NOTHING that you would include at the top
> of every PHP file? Not even one include? What about a single include
> which would pull in info or set settings relevant to the environment?
> For example
>
> require_once "current_env.php";
>
No, there is not.
> The idea of that would be to set settings relevant to the environment in
> which the PHP script is to run. There might be many current_env.php
> files, one for each environment, but all of them would set up things
> needed for the including PHP program to run properly.
>
> Any good?
>
A good programmer knows how to do it in any sane PHP environment. One
which, for instance, has the recommended settings from Zend. And I
NEVER have to change the runtime environment.
>>>>>> I told you what I put in such a preamble - nothing other than
>>>>>> common classes which I've developed and userids/passwords.
>>>>>> And I haven't, for around 15 years of PHP programming and
>>>>>> thousands of PHP pages. I don't need them because I use good
>>>>>> programing practices instead of snarky work-arounds which
>>>>>> cause more problems in the long run.
>>>>>
>>>>> It sounds like you do what you are complaining about me
>>>>> suggesting...!
>>>>>
>>>>> James
>>>>>
>>>>
>>>> Not at all. Common classes are reusable code (i.e. database
>>>> access classes). Userids and passwords should NEVER be in a file
>>>> that's in the server's DOCUMENT_ROOT.
>>>
>>> I did not say that the stuff included had to be under the
>>> DOCUMENT_ROOT.
>>>
>>> James
>>>
>>
>> *I* said the userids and passwords should *not* be under the
>> DOCUMENT_ROOT.
>
> I know. As with elsewhere in this thread you seem to object to the
> places where I expressed agreement with you.
>
> James
I'm just pointing out once again that you're implying I said something I
never did.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Denis McMahon <denismfmcmahon@gmail.com> |
|---|---|
| Date | 2015-12-20 22:54 +0000 |
| Message-ID | <n57bjv$2t5$1@dont-email.me> |
| In reply to | #15929 |
On Sun, 20 Dec 2015 17:11:31 +0000, James Harris wrote:
> A simple example is the page title. Consider emitting
>
> <title>T</title>
>
> There is to be a certain title, T, if everything is normal and a
> different title if something goes wrong. I cannot produce that line or
> anything after it (which essentially includes all the page content)
> until I know whether there are any errors or not. (Such errors are not
> from bugs but from runtime issues such as absence of resources.)
>
> Since you object to what I am doing what would you do for such a title
> problem?
At the end of your php:
// assemble the page
$page = <<< EOT
<!doctype html>
<html lang='en'>
<head>
{$head}
</head>
<body>
{$body}
</body>
</html>
EOT;
// and deliver it
echo $page;
where $head and $body contain whatever head and body elements you want to
include.
This way you can handle any "runtime issues" that you encounter during
processing and incorporate suitable content in both the head and body of
the generated page.
Jerry may have a better suggestion.
--
Denis McMahon, denismfmcmahon@gmail.com
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-20 18:40 -0500 |
| Message-ID | <n57e3o$fn4$1@jstuckle.eternal-september.org> |
| In reply to | #15931 |
On 12/20/2015 5:54 PM, Denis McMahon wrote:
> On Sun, 20 Dec 2015 17:11:31 +0000, James Harris wrote:
>
>> A simple example is the page title. Consider emitting
>>
>> <title>T</title>
>>
>> There is to be a certain title, T, if everything is normal and a
>> different title if something goes wrong. I cannot produce that line or
>> anything after it (which essentially includes all the page content)
>> until I know whether there are any errors or not. (Such errors are not
>> from bugs but from runtime issues such as absence of resources.)
>>
>> Since you object to what I am doing what would you do for such a title
>> problem?
>
> At the end of your php:
>
> // assemble the page
> $page = <<< EOT
> <!doctype html>
> <html lang='en'>
> <head>
> {$head}
> </head>
> <body>
> {$body}
> </body>
> </html>
> EOT;
>
> // and deliver it
> echo $page;
>
> where $head and $body contain whatever head and body elements you want to
> include.
>
> This way you can handle any "runtime issues" that you encounter during
> processing and incorporate suitable content in both the head and body of
> the generated page.
>
> Jerry may have a better suggestion.
>
That's one way to do it. But I do the critical processing before any
output, then redirect if necessary. For instance, if I need to search a
database, I perform the search first. If it fails, I take appropriate
action. If there is no failure, I start outputting the page, processing
the results as necessary.
It's not important if there are zero results from the search; it just
means nothing satisfied the request. For instance, a search for punk
rock records by Frank Sinatra would be valid, but return zero results.
If I have an error while I'm outputting the result (i.e. database
crashed during processing), I'll display a message then. Sure, part of
the page has already been output. But the fact the user gets that much
really isn't important; it happens maybe once in 10,000,000 or more
calls - often enough that it needs to be handled, but not often enough
to screw up all kinds of processing (and waste system resources on every
call) just in case it does happen.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-12-21 10:38 +0100 |
| Message-ID | <2838299.zdqeYZrqYU@PointedEars.de> |
| In reply to | #15925 |
James Harris wrote:
> In the interests of getting a consistent approach to developing PHP
> programs do you guys have any guidelines you follow and/or boilerplate
> you include when writing a new piece of PHP? For HTML output I mean
> things like the following.
>
> At the top of the code: setup such as error_reporting, ini_set etc and
Only for live debugging on productive systems where there is no development
fallback. Otherwise I would set that up in the php.ini, the Virtual Host
configuration or the .htaccess/.config file *once*.
> constant definitions.
Yes.
> Use of ob_start before the code generates 'normal' output so that the
> program can present custom error information if something goes wrong.
Again, that is something better enabled for the whole site (in index.php,
which should trigger almost everything else) or something enabled for a
specific part of the code for a specific purpose.
> A fail() function which will ob_end_clean and then render a suitable
> failure HTML page.
I never had a need for that. Errors should be fixed in the development
stage, and if they occur in production, it is better that they are not
printed and that, instead of a document of unknown composition, nothing is
displayed to the user.
> Some sort of debugging functions which will work with output buffer
> capture to generate sensible debug output.
Debug output on production systems belongs in log files that are not
publicly accessible; not in the browser viewport for every potential
attacker to see.
> Is there anything else that should be present at the top of a piece of
> code?
The namespace declarations, if any. Before that, the software license or
reference to it.
> Given the fact that some of the above may vary between environments such
> as test and production is it feasible to pull in something like the
> above with
>
> require_once("preamble_code.php");
No. And you should write
require_once 'foo.php';
instead.
> […]
> If some of the above can be parameterised might it even be possible to
> come up with a universal module that can be pulled in with require_once
> (and then the functions within it called with certain parameters)?
Breaking a fly on a badly reinvented wheel.
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-21 08:41 -0500 |
| Message-ID | <n58vds$ruv$1@jstuckle.eternal-september.org> |
| In reply to | #15933 |
On 12/21/2015 4:38 AM, Thomas 'PointedEars' Lahn wrote:
> James Harris wrote:
>
>> In the interests of getting a consistent approach to developing PHP
>> programs do you guys have any guidelines you follow and/or boilerplate
>> you include when writing a new piece of PHP? For HTML output I mean
>> things like the following.
>>
>> At the top of the code: setup such as error_reporting, ini_set etc and
>
> Only for live debugging on productive systems where there is no development
> fallback. Otherwise I would set that up in the php.ini, the Virtual Host
> configuration or the .htaccess/.config file *once*.
>
You should always have a development machine, with the same settings as
those on the server.
>> constant definitions.
>
> Yes.
>
>> Use of ob_start before the code generates 'normal' output so that the
>> program can present custom error information if something goes wrong.
>
> Again, that is something better enabled for the whole site (in index.php,
> which should trigger almost everything else) or something enabled for a
> specific part of the code for a specific purpose.
>
Only someone who uses a CMS triggers everything from index.php.
Programmers developing a site from scratch know there are better ways of
doing things.
>> A fail() function which will ob_end_clean and then render a suitable
>> failure HTML page.
>
> I never had a need for that. Errors should be fixed in the development
> stage, and if they occur in production, it is better that they are not
> printed and that, instead of a document of unknown composition, nothing is
> displayed to the user.
>
NEVER display a blank page to the user. You may not provide details of
the error, but you need to let the user know an error occurred, with
information that can be passed on to the programmer.
>> Some sort of debugging functions which will work with output buffer
>> capture to generate sensible debug output.
>
> Debug output on production systems belongs in log files that are not
> publicly accessible; not in the browser viewport for every potential
> attacker to see.
>
Yes and no. You need to provide enough general information to the user
so that the programmer knows where to look in the logs.
>> Is there anything else that should be present at the top of a piece of
>> code?
>
> The namespace declarations, if any. Before that, the software license or
> reference to it.
>
I've found limited need for namespaces in PHP. This isn't C++, and
scripts don't need to include conflicting definitions. Even the PHP
documentation has examples which show how namespaces complicate the
code. And nothing in them can't be done without namespaces.
>> Given the fact that some of the above may vary between environments such
>> as test and production is it feasible to pull in something like the
>> above with
>>
>> require_once("preamble_code.php");
>
> No. And you should write
>
> require_once 'foo.php';
>
> instead.
>
A matter of style, only. Both are acceptable.
>> […]
>> If some of the above can be parameterised might it even be possible to
>> come up with a universal module that can be pulled in with require_once
>> (and then the functions within it called with certain parameters)?
>
> Breaking a fly on a badly reinvented wheel.
>
Agreed here.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-12-21 15:30 +0100 |
| Message-ID | <1473248.ziGLShfuNh@PointedEars.de> |
| In reply to | #15934 |
Jerry Stuckle wrote:
> On 12/21/2015 4:38 AM, Thomas 'PointedEars' Lahn wrote:
>> James Harris wrote:
>>> At the top of the code: setup such as error_reporting, ini_set etc and
>> Only for live debugging on productive systems where there is no
>> development fallback. Otherwise I would set that up in the php.ini, the
>> Virtual Host configuration or the .htaccess/.config file *once*.
>
> You should always have a development machine, with the same settings as
> those on the server.
Not always possible.
>>> Use of ob_start before the code generates 'normal' output so that the
>>> program can present custom error information if something goes wrong.
>> Again, that is something better enabled for the whole site (in index.php,
>> which should trigger almost everything else) or something enabled for a
>> specific part of the code for a specific purpose.
>
> Only someone who uses a CMS triggers everything from index.php.
> Programmers developing a site from scratch know there are better ways of
> doing things.
You have no clue what you are talking about.
In order to disprove your hastily generalized statement I need only one
counter-example:
<https://magento.com/>
>>> A fail() function which will ob_end_clean and then render a suitable
>>> failure HTML page.
>> I never had a need for that. Errors should be fixed in the development
>> stage, and if they occur in production, it is better that they are not
>> printed and that, instead of a document of unknown composition, nothing
>> is displayed to the user.
>
> NEVER display a blank page to the user. You may not provide details of
> the error, but you need to let the user know an error occurred, with
> information that can be passed on to the programmer.
A matter of opinion. IBTD.
>>> require_once("preamble_code.php");
>> […] you should write
>>
>> require_once 'foo.php';
>>
>> instead.
>
> A matter of style, only. Both are acceptable.
That depends on whether you (need to) adhere to a certain code style.
For example, if you need to adhere to PSR-2, you need to write it as
I suggested:
<http://www.php-fig.org/psr/psr-2/>
Please trim your quotes to the relevant minimum.
--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-21 11:04 -0500 |
| Message-ID | <n597pd$tn8$1@jstuckle.eternal-september.org> |
| In reply to | #15935 |
On 12/21/2015 9:30 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 12/21/2015 4:38 AM, Thomas 'PointedEars' Lahn wrote:
>>> James Harris wrote:
>>>> At the top of the code: setup such as error_reporting, ini_set etc and
>>> Only for live debugging on productive systems where there is no
>>> development fallback. Otherwise I would set that up in the php.ini, the
>>> Virtual Host configuration or the .htaccess/.config file *once*.
>>
>> You should always have a development machine, with the same settings as
>> those on the server.
>
> Not always possible.
>
In close to 25 years of web programming, I've NEVER found it impossible.
What you mean is it's not always possible - FOR YOU.
>>>> Use of ob_start before the code generates 'normal' output so that the
>>>> program can present custom error information if something goes wrong.
>>> Again, that is something better enabled for the whole site (in index.php,
>>> which should trigger almost everything else) or something enabled for a
>>> specific part of the code for a specific purpose.
>>
>> Only someone who uses a CMS triggers everything from index.php.
>> Programmers developing a site from scratch know there are better ways of
>> doing things.
>
> You have no clue what you are talking about.
>
> In order to disprove your hastily generalized statement I need only one
> counter-example:
>
> <https://magento.com/>
>
Which is a cms. I rest my case.
>>>> A fail() function which will ob_end_clean and then render a suitable
>>>> failure HTML page.
>>> I never had a need for that. Errors should be fixed in the development
>>> stage, and if they occur in production, it is better that they are not
>>> printed and that, instead of a document of unknown composition, nothing
>>> is displayed to the user.
>>
>> NEVER display a blank page to the user. You may not provide details of
>> the error, but you need to let the user know an error occurred, with
>> information that can be passed on to the programmer.
>
> A matter of opinion. IBTD.
>
A matter of good programming practice. But you have no idea what that
is. You don't even know what a CMS is!
>>>> require_once("preamble_code.php");
>>> […] you should write
>>>
>>> require_once 'foo.php';
>>>
>>> instead.
>>
>> A matter of style, only. Both are acceptable.
>
> That depends on whether you (need to) adhere to a certain code style.
> For example, if you need to adhere to PSR-2, you need to write it as
> I suggested:
>
> <http://www.php-fig.org/psr/psr-2/>
>
> Please trim your quotes to the relevant minimum.
>
As I said - it's a matter of style. But you need to argue - even though
you agree it's a matter of style!
Trolls of the world, unite around your leader - Pointed Head!
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2015-12-21 23:24 +0100 |
| Message-ID | <4625100.rdbKtHyMP0@PointedEars.de> |
| In reply to | #15936 |
Jerry Stuckle wrote: > On 12/21/2015 9:30 AM, Thomas 'PointedEars' Lahn wrote: >> Jerry Stuckle wrote: > > [ad-hominem fallacy] > >>>>> Use of ob_start before the code generates 'normal' output so that the >>>>> program can present custom error information if something goes wrong. >>>> Again, that is something better enabled for the whole site (in >>>> index.php, which should trigger almost everything else) or something >>>> enabled for a specific part of the code for a specific purpose. >>> >>> Only someone who uses a CMS triggers everything from index.php. >>> Programmers developing a site from scratch know there are better ways of >>> doing things. >> >> You have no clue what you are talking about. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> In order to disprove your hastily generalized statement I need only one >> counter-example: >> >> <https://magento.com/> > > Which is a cms. I rest my case. Q.E.D. First and foremost, Magento is an *e-commerce platform*; one uses it to build *Web shops*. It includes by default a CMS *extension* for easily editing certain parts of the Web shop (such as “About”), but using that feature is in no wise a requirement nor has it anything to do with the controller-based routing that the Magento Framework does in *any* case (even when no “CMS pages” are involved). > [ad-hominem fallacy] -- PointedEars Zend Certified PHP Engineer Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-21 19:16 -0500 |
| Message-ID | <n5a4kk$jc5$1@jstuckle.eternal-september.org> |
| In reply to | #15939 |
On 12/21/2015 5:24 PM, Thomas 'PointedEars' Lahn wrote: > Jerry Stuckle wrote: > >> On 12/21/2015 9:30 AM, Thomas 'PointedEars' Lahn wrote: >>> Jerry Stuckle wrote: >> >> [ad-hominem fallacy] >> >>>>>> Use of ob_start before the code generates 'normal' output so that the >>>>>> program can present custom error information if something goes wrong. >>>>> Again, that is something better enabled for the whole site (in >>>>> index.php, which should trigger almost everything else) or something >>>>> enabled for a specific part of the code for a specific purpose. >>>> >>>> Only someone who uses a CMS triggers everything from index.php. >>>> Programmers developing a site from scratch know there are better ways of >>>> doing things. >>> >>> You have no clue what you are talking about. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> In order to disprove your hastily generalized statement I need only one >>> counter-example: >>> >>> <https://magento.com/> >> >> Which is a cms. I rest my case. > > Q.E.D. First and foremost, Magento is an *e-commerce platform*; one uses it > to build *Web shops*. It includes by default a CMS *extension* for easily > editing certain parts of the Web shop (such as “About”), but using that > feature is in no wise a requirement nor has it anything to do with the > controller-based routing that the Magento Framework does in *any* case (even > when no “CMS pages” are involved). > >> [ad-hominem fallacy] > Which is a CMS. But you're too stoopid to understand that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2015-12-22 00:33 +0100 |
| Message-ID | <n5a244$959$1@dont-email.me> |
| In reply to | #15936 |
Am 2015-12-21 um 17:04 schrieb Jerry Stuckle: > In close to 25 years of web programming [snip] What is "close to"? Since the web itself is barely 25 years old, you must be either Tim Berners-Lee himself or you are blatantly exaggerating. Besides: I know "developers" who have done "web development" for years and their code quality hasn't improved in the slightest during this time. Gregor
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-12-21 19:19 -0500 |
| Message-ID | <n5a4pp$jc5$2@jstuckle.eternal-september.org> |
| In reply to | #15942 |
On 12/21/2015 6:33 PM, Gregor Kofler wrote: > Am 2015-12-21 um 17:04 schrieb Jerry Stuckle: > >> In close to 25 years of web programming [snip] > > What is "close to"? > > Since the web itself is barely 25 years old, you must be either Tim > Berners-Lee himself or you are blatantly exaggerating. > > Besides: I know "developers" who have done "web development" for years > and their code quality hasn't improved in the slightest during this time. > > Gregor > > I started back in about 1991. But I was on arpanet long before that. But if you claim you know "developers" who have done "web development" for years, then you don't know real developers. I have around 47 years of programming total, in close to 20 different language (including 13 years at IBM). What do your "developers" have? Or are you just an ignorant troll like Pointed Head? I suspect so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web