PHP programming strategy

Is anyone here interested in discussing programming strategy, or or know of a discussion
group which is interested in the subject?

The sorts of questions I am interested in are:

1. I have a highly variable program which always shows the same page, but which includes
different modules to give different results. The various modules call on different
functions. Is it better to minimise memory by including only the functions actually
required, but increase the number of files included, or to bundle all the functions into
one file, thereby reducing the number of files included but increasing the size in memory?

2. As PHP is an interpreted program comments certainly increase the memory requirements,
and presumably they slow down the operation of the program. Would stripping out the
comments before uploading the production version give any visible improvement in
performance?


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

On Saturday 01 August 2009 8:25:40 pm Clancy wrote:
> Is anyone here interested in discussing programming strategy, or or know of
> a discussion group which is interested in the subject?
>
> The sorts of questions I am interested in are:
>
> 1. I have a highly variable program which always shows the same page, but
> which includes different modules to give different results. The various
> modules call on different functions. Is it better to minimise memory by
> including only the functions actually required, but increase the number of
> files included, or to bundle all the functions into one file, thereby
> reducing the number of files included but increasing the size in memory?

That depends greatly on your usage patterns. Does your application make lots
of "sideways" calls to integrate different modules, or is just "switch on a GET
parameter, run this function, done"? If the latter, then lazy-loading just
the one or two files you want is probably better. If the former, you'd need a
lot of interesting logic to make lazy-loading work well enough to be justified.
(I've been working on such a system for Drupal for the past year, and it's not
easy to get right because there can be a fair bit of overhead.)

If your application is heavily OOP then PHP supports dynamic autoloading of
classes, which can greatly simplify your code logic but at the same time the
autoload mechanism itself is not free either.

The age of the computer matters, too. Modern hard drives are faster than they
used to be, and more recent OS versions can do some fairly aggressive caching
if the files you're reading all fit inside the OS cache somewhere in memory so
you may not actually hit disk to "load" each of your files.

> 2. As PHP is an interpreted program comments certainly increase the memory
> requirements, and presumably they slow down the operation of the program.
> Would stripping out the comments before uploading the production version
> give any visible improvement in performance?

I actually benchmarked that once. I had a reasonably large PHP file that was,
in fact, over 50% docblocks. That's not even counting inline comments. While
trying to find things to optimize, removing about 800 lines worth of comments
(all of the docblocks) did, in fact, produce a noticeable performance
difference. It was only barely noticeable, but it just barely registered as
more than random sampling jitter. I actually concluded that if cutting the
file *in half* was only just barely noticeable, then it really wasn't worth the
effort.

Just install an opcode cache. That will take care of most of your memory
issues. :-)

--
Larry Garfield
larry@garfieldtech.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

> I actually benchmarked that once.  I had a reasonably large PHP file=
that was,
> in fact, over 50% docblocks.  That's not even counting inline commen=
ts.  While
> trying to find things to optimize, removing about 800 lines worth of comm=
ents
> (all of the docblocks) did, in fact, produce a noticeable performance
> difference.  It was only barely noticeable, but it just barely regis=
tered as
> more than random sampling jitter.  I actually concluded that if cutt=
ing the
> file *in half* was only just barely noticeable, then it really wasn't wor=
th the
> effort.

Yeah but what happens if you run the script through the tokenizer and
strip ALL comments, unnecessary whitespace, newline characters, etc.
out?

> Larry Garfield
> larry@garfieldtech.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

On Sun, Aug 02, 2009 at 11:25:40AM +1000, Clancy wrote:

> Is anyone here interested in discussing programming strategy, or or know
> of a discussion
> group which is interested in the subject?
>
> The sorts of questions I am interested in are:
>
> 1. I have a highly variable program which always shows the same page,
> but which includes
> different modules to give different results. The various modules call
> on different
> functions. Is it better to minimise memory by including only the functions
> actually
> required, but increase the number of files included, or to bundle all the
> functions into
> one file, thereby reducing the number of files included but increasing
> the size in memory?

My advice would be to only load the modules you need, no matter how
convoluted the logic you must use to do that. A lot of PHP programmers
are very sloppy about memory usage, falling back on the cache argument,
etc. But there's no reason to use more memory than you have to.

However, there is an issue if all these modules are scattered about
everywhere. You also have to look at the overhead on the server when
it's having to open 15 files for every page displayed. That's silly as
well.

So it's a trade-off. If you have the latter problem, I'd probably opt to
put everything in one or a few files. In my opinion, disk thrashing on a
busy internet server is worse than gobbling up more memory. That disk
thrashing is likely to have a negative effect on all the other users of
that server.

>
> 2. As PHP is an interpreted program comments certainly increase the memory
> requirements,
> and presumably they slow down the operation of the program. Would stripping
> out the
> comments before uploading the production version give any visible
> improvement in
> performance?
>

I bow to those who have profiled this, as far as performance goes.
However, remember, you have to *maintain* this code. In a trade-off
between performance and maintainability, I'd opt for maintainability.
You'll thank yourself in the future.

Paul


--
Paul M. Foster

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

On Saturday 01 August 2009 11:01:11 pm Eddie Drapkin wrote:
> > I actually benchmarked that once. I had a reasonably large PHP file that
> > was, in fact, over 50% docblocks. That's not even counting inline
> > comments. While trying to find things to optimize, removing about 800
> > lines worth of comments (all of the docblocks) did, in fact, produce a
> > noticeable performance difference. It was only barely noticeable, but it
> > just barely registered as more than random sampling jitter. I actually
> > concluded that if cutting the file *in half* was only just barely
> > noticeable, then it really wasn't worth the effort.
>
> Yeah but what happens if you run the script through the tokenizer and
> strip ALL comments, unnecessary whitespace, newline characters, etc.
> out?

Honestly? I think you'll save more CPU time by eliminating one SQL query.
Most files are not 60% comments. In a file that is only about 20% comments, I
doubt you could even measure the difference. There are far far far more useful
ways to optimize your code.

(Note that this is different for CSS or Javascript, where compressors like that
are commonplace because you have to transfer the entire file over the network
repeatedly, which is a few orders of magnitude slower than system memory.
Compressors and aggregators there make sense. PHP code never leaves the
server, so those benefits don't exist.)

--
Larry Garfield
larry@garfieldtech.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

On Sun, Aug 2, 2009 at 2:24 PM, Larry Garfield wrot=
e:
> On Saturday 01 August 2009 11:01:11 pm Eddie Drapkin wrote:
>> > I actually benchmarked that once.  I had a reasonably large PHP f=
ile that
>> > was, in fact, over 50% docblocks.  That's not even counting inlin=
e
>> > comments.  While trying to find things to optimize, removing abou=
t 800
>> > lines worth of comments (all of the docblocks) did, in fact, produce a
>> > noticeable performance difference.  It was only barely noticeable=
, but it
>> > just barely registered as more than random sampling jitter.  I ac=
tually
>> > concluded that if cutting the file *in half* was only just barely
>> > noticeable, then it really wasn't worth the effort.
>>
>> Yeah but what happens if you run the script through the tokenizer and
>> strip ALL comments, unnecessary whitespace, newline characters, etc.
>> out?
>
> Honestly?  I think you'll save more CPU time by eliminating one SQL =
query.
> Most files are not 60% comments.  In a file that is only about 20% c=
omments, I
> doubt you could even measure the difference.  There are far far far =
more useful
> ways to optimize your code.
>
> (Note that this is different for CSS or Javascript, where compressors lik=
e that
> are commonplace because you have to transfer the entire file over the net=
work
> repeatedly, which is a few orders of magnitude slower than system memory.
> Compressors and aggregators there make sense.  PHP code never leaves=
the
> server, so those benefits don't exist.)
>
> --
> Larry Garfield
> larry@garfieldtech.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Seems the sarcasm / attempted comedy was lost in translation!

--Eddie

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

On Sun, 02 Aug 2009 04:25:40 +0300, Clancy wrote:

> Is anyone here interested in discussing programming strategy, or or know
> of a discussion
> group which is interested in the subject?
>
> The sorts of questions I am interested in are:
>
> 1. I have a highly variable program which always shows the same page,
> but which includes
> different modules to give different results. The various modules call
> on different
> functions. Is it better to minimise memory by including only the
> functions actually
> required, but increase the number of files included, or to bundle all
> the functions into
> one file, thereby reducing the number of files included but increasing
> the size in memory?
>
> 2. As PHP is an interpreted program comments certainly increase the
> memory requirements,
> and presumably they slow down the operation of the program. Would
> stripping out the
> comments before uploading the production version give any visible
> improvement in
> performance?
>
I think, first question you should answer following questions:
1. How large is your workload ?
2. How it is easier to develop this program?
3. can you logically split functions to different modules ?
4. Did you used other methods of optimizations ?

This questions is important because:
1. if you don't have huge workload - this kind of optimization won't help
you at all. just will take time needed for actual divelopment.

2. PHP Compiler are already fast enough. So if you don't have very
high-load website, then it is more important how fast you write program,
rather than how many files do you have.

3. If you can logically split them - then it is good to split them,
because it will easier to develop them.
Mostly, I personally try to separate functions to a modules:
I have 2-3 files per action: skin file, and action file. Sometimes:
datatype file (for functions related to information type, like "Person")
Also I have like 10 library files: they have all functions related to this
library: "skins" , "person related", etc.

This is optimanl, because I can easily find whatever I need when
developing.

4. If you have huge load, then it is much more efficient (and easier) to
use other methods. For Example: install APC (http://fi2.php.net/apc )
It will cache all requests to your files and this will have huge impact on
your performance. Much more than you can achieve by stripping comments on
moving functions around. (and it is also very easy to install)

Also Memcached & Mysql optimization may help a lot.






--

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

Ollisso wrote:

>
> 4. If you have huge load, then it is much more efficient (and easier) to
> use other methods. For Example: install APC (http://fi2.php.net/apc )
> It will cache all requests to your files and this will have huge impact
> on your performance. Much more than you can achieve by stripping
> comments on moving functions around. (and it is also very easy to install)
>
> Also Memcached & Mysql optimization may help a lot.
>
>

Unfortunately I had to turn of APC file caching because it had conflicts
with mdb2. So the only benefit I see from APC is manual caching (mostly
db queries).

APC also seems to have broken uploadprogress - I guess I could switch to
using APC's built in upload progress, but I really prefer to have code
that works whether or not APC is enabled.

Hopefully these issues can be worked around.
I may be able to use come kind of regex to get APC to ignore pear files,
or maybe mdb2 can be patched to no longer have a conflict with apc.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: PHP programming strategy

Thank you to all of you who have commented on this query.

On the subject of comments, I feel that Larry Garfield settled this query by pointing out
that halving the size of a particular document gave a barely noticeable increase in speed.
Paul Foster pointed out the problem of maintenance, but if, as I do, you do your
development in-house, and then upload the working copies of the program, it would be
possible to strip out comments when you upload it. If you were really paranoid, this could
have the advantage that if somebody managed to steal your code from the server it would be
that much harder for them to understand. On the other hand the process of stripping out
the comments could potentially introduce new bugs, and I think this consideration would
outweigh anything else.

I have recently come to the conclusion that I should never consider anything completed
until I have analysed the HTML code for an actual page. It is amazing how badly mangled
tables and the like can be without producing any visible effect on the page, and on
several occasions I have found PHP error messages which were mixed up with the HTML in
such a way that they were not displayed at all. On at least one occasion this gave me the
clue to an otherwise baffling bug.

I have also discovered that the process of analysing the HTML is made substantially
simpler by inserting HTML comments into the output; e.g. instead of

Echo '';
write
?>




Unfortunately, for HTML readability, it is highly desirable not to indent the code, and if
you are trying to have nicely indented braces, this makes the PHP code that much harder to
interpret.

And on the question of functions there is some virtue (primarily from the point of view of
maintenance) in not having individual files too large, so while it seems to be the general
consensus that splitting up functions into groups to give smaller files will probably slow
things down a bit, if they can be grouped into sets which are only loaded in particular
circumstances this would be worth doing.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> Thank you to all of you who have commented on this query.
>
> On the subject of comments, I feel that Larry Garfield settled this query by pointing out
> that halving the size of a particular document gave a barely noticeable increase in speed.
> Paul Foster pointed out the problem of maintenance, but if, as I do, you do your
> development in-house, and then upload the working copies of the program, it would be
> possible to strip out comments when you upload it. If you were really paranoid, this could
> have the advantage that if somebody managed to steal your code from the server it would be
> that much harder for them to understand. On the other hand the process of stripping out
> the comments could potentially introduce new bugs, and I think this consideration would
> outweigh anything else.
>
> I have recently come to the conclusion that I should never consider anything completed
> until I have analysed the HTML code for an actual page. It is amazing how badly mangled
> tables and the like can be without producing any visible effect on the page, and on
> several occasions I have found PHP error messages which were mixed up with the HTML in
> such a way that they were not displayed at all. On at least one occasion this gave me the
> clue to an otherwise baffling bug.
>
> I have also discovered that the process of analysing the HTML is made substantially
> simpler by inserting HTML comments into the output; e.g. instead of
>
> Echo '';
> write
> ?>
>
> >
>
> >
> Unfortunately, for HTML readability, it is highly desirable not to indent the code, and if
> you are trying to have nicely indented braces, this makes the PHP code that much harder to
> interpret.
>
> And on the question of functions there is some virtue (primarily from the point of view of
> maintenance) in not having individual files too large, so while it seems to be the general
> consensus that splitting up functions into groups to give smaller files will probably slow
> things down a bit, if they can be grouped into sets which are only loaded in particular
> circumstances this would be worth doing.
>
>
Nested tables are the devils playthings!

Thanks,
Ash
http://www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan w=
rote:
> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
>> Thank you to all of you who have commented on this query.
>>
>> On the subject of comments, I feel that Larry Garfield settled this quer=
y by pointing out
>> that halving the size of a particular document gave a barely noticeable =
increase in speed.
>> Paul Foster pointed out the problem of maintenance, but if, as I do, you=
do your
>> development in-house, and then upload the working copies of the program,=
it would be
>> possible to strip out comments when you upload it. If you were really pa=
ranoid, this could
>> have the advantage that if somebody managed to steal your code from the =
server it would be
>> that much harder for them to understand. On the other hand the process o=
f stripping out
>> the comments could potentially introduce new bugs, and I think this cons=
ideration would
>> outweigh anything else.
>>
>> I have recently come to the conclusion that I should never consider anyt=
hing completed
>> until I have analysed the HTML code for an actual page. It is amazing ho=
w badly mangled
>> tables and the like can be without producing any visible effect on the p=
age, and on
>> several occasions I have found PHP error messages which were mixed up wi=
th the HTML in
>> such a way that they were not displayed at all. On at least one occasion=
this gave me the
>> clue to an otherwise baffling bug.
>>
>> I have also discovered that the process of analysing the HTML is made su=
bstantially
>> simpler by inserting HTML comments into the output; e.g. instead of
>>
>> =A0 =A0 =A0 Echo '';
>> write
>> ?>
>>
>> >>
>>
>> >>
>> Unfortunately, for HTML readability, it is highly desirable not to inden=
t the code, and if
>> you are trying to have nicely indented braces, this makes the PHP code t=
hat much harder to
>> interpret.
>>
>> And on the question of functions there is some virtue (primarily from th=
e point of view of
>> maintenance) in not having individual files too large, so while it seems=
to be the general
>> consensus that splitting up functions into groups to give smaller files =
will probably slow
>> things down a bit, if they can be grouped into sets which are only loade=
d in particular
>> circumstances this would be worth doing.
>>
>>
> Nested tables are the devils playthings!
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

I would agree there...we have an app that allows users to create forms
dynamically with a left and right panel section along with some full
width plug-in. At a minimum this is built with three nested tables.
Here's the really rotten part, the VP (original dev for the display
code) screwed a table close up somewhere. A bug they found literally
minutes before it when to prod at a client site, instead of giving me
15 minutes to trace it down, they wrapped the entire table structure
in another table to make it look pretty.

Drives me mental as it produces lots a visual screw up when a certain
pattern in the form elements is created

--=20

Bastien

Cat, the other other white meat

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Wed, 5 Aug 2009 09:25:20 -0400, phpster@gmail.com (Bastien Koert) wrote:

>On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan wrote:
>> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
>>> Thank you to all of you who have commented on this query.
>>>
>>> On the subject of comments, I feel that Larry Garfield settled this query by pointing out
>>> that halving the size of a particular document gave a barely noticeable increase in speed.
>>> Paul Foster pointed out the problem of maintenance, but if, as I do, you do your
>>> development in-house, and then upload the working copies of the program, it would be
>>> possible to strip out comments when you upload it. If you were really paranoid, this could
>>> have the advantage that if somebody managed to steal your code from the server it would be
>>> that much harder for them to understand. On the other hand the process of stripping out
>>> the comments could potentially introduce new bugs, and I think this consideration would
>>> outweigh anything else.
>>>
>>> I have recently come to the conclusion that I should never consider anything completed
>>> until I have analysed the HTML code for an actual page. It is amazing how badly mangled
>>> tables and the like can be without producing any visible effect on the page, and on
>>> several occasions I have found PHP error messages which were mixed up with the HTML in
>>> such a way that they were not displayed at all. On at least one occasion this gave me the
>>> clue to an otherwise baffling bug.
>>>
>>> I have also discovered that the process of analysing the HTML is made substantially
>>> simpler by inserting HTML comments into the output; e.g. instead of
>>>
>>>       Echo '';
>>> write
>>> ?>
>>>
>>> >>>
>>>
>>> >>>
>>> Unfortunately, for HTML readability, it is highly desirable not to indent the code, and if
>>> you are trying to have nicely indented braces, this makes the PHP code that much harder to
>>> interpret.
>>>
>>> And on the question of functions there is some virtue (primarily from the point of view of
>>> maintenance) in not having individual files too large, so while it seems to be the general
>>> consensus that splitting up functions into groups to give smaller files will probably slow
>>> things down a bit, if they can be grouped into sets which are only loaded in particular
>>> circumstances this would be worth doing.
>>>
>>>
>> Nested tables are the devils playthings!

I must be the devil, then. I enjoy playing with them. And if they're done right they
seem to work on every system I have tried them on. Granted Dreamweaver design mode gets
its knickers in a knot if you nest them more than about 4 deep.

>>
>> Thanks,
>> Ash
>> http://www.ashleysheridan.co.uk
>>
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
>I would agree there...we have an app that allows users to create forms
>dynamically with a left and right panel section along with some full
>width plug-in. At a minimum this is built with three nested tables.
>Here's the really rotten part, the VP (original dev for the display
>code) screwed a table close up somewhere. A bug they found literally
>minutes before it when to prod at a client site, instead of giving me
>15 minutes to trace it down, they wrapped the entire table structure
>in another table to make it look pretty.

Clearly he didn't verify the HTML before he released the original version. ;-)
>
>Drives me mental as it produces lots a visual screw up when a certain
>pattern in the form elements is created

That's the joy of HTML errors - often the output will appear normal until you make some
minor, and apparently irrelevant, change, when it all goes haywire.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> On Wed, 5 Aug 2009 09:25:20 -0400, phpster@gmail.com (Bastien Koert) wrote:
>
> >On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan wrote:
> >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> >>> Thank you to all of you who have commented on this query.
> >>>
> >>> On the subject of comments, I feel that Larry Garfield settled this query by pointing out
> >>> that halving the size of a particular document gave a barely noticeable increase in speed.
> >>> Paul Foster pointed out the problem of maintenance, but if, as I do, you do your
> >>> development in-house, and then upload the working copies of the program, it would be
> >>> possible to strip out comments when you upload it. If you were really paranoid, this could
> >>> have the advantage that if somebody managed to steal your code from the server it would be
> >>> that much harder for them to understand. On the other hand the process of stripping out
> >>> the comments could potentially introduce new bugs, and I think this consideration would
> >>> outweigh anything else.
> >>>
> >>> I have recently come to the conclusion that I should never consider anything completed
> >>> until I have analysed the HTML code for an actual page. It is amazing how badly mangled
> >>> tables and the like can be without producing any visible effect on the page, and on
> >>> several occasions I have found PHP error messages which were mixed up with the HTML in
> >>> such a way that they were not displayed at all. On at least one occasion this gave me the
> >>> clue to an otherwise baffling bug.
> >>>
> >>> I have also discovered that the process of analysing the HTML is made substantially
> >>> simpler by inserting HTML comments into the output; e.g. instead of
> >>>
> >>> Echo '';
> >>> write
> >>> ?>
> >>>
> >>> > >>>
> >>>
> >>> > >>>
> >>> Unfortunately, for HTML readability, it is highly desirable not to indent the code, and if
> >>> you are trying to have nicely indented braces, this makes the PHP code that much harder to
> >>> interpret.
> >>>
> >>> And on the question of functions there is some virtue (primarily from the point of view of
> >>> maintenance) in not having individual files too large, so while it seems to be the general
> >>> consensus that splitting up functions into groups to give smaller files will probably slow
> >>> things down a bit, if they can be grouped into sets which are only loaded in particular
> >>> circumstances this would be worth doing.
> >>>
> >>>
> >> Nested tables are the devils playthings!
>
> I must be the devil, then. I enjoy playing with them. And if they're done right they
> seem to work on every system I have tried them on. Granted Dreamweaver design mode gets
> its knickers in a knot if you nest them more than about 4 deep.
>
> >>
> >> Thanks,
> >> Ash
> >> http://www.ashleysheridan.co.uk
> >>
> >>
> >> --
> >> PHP General Mailing List (http://www.php.net/)
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >
> >I would agree there...we have an app that allows users to create forms
> >dynamically with a left and right panel section along with some full
> >width plug-in. At a minimum this is built with three nested tables.
> >Here's the really rotten part, the VP (original dev for the display
> >code) screwed a table close up somewhere. A bug they found literally
> >minutes before it when to prod at a client site, instead of giving me
> >15 minutes to trace it down, they wrapped the entire table structure
> >in another table to make it look pretty.
>
> Clearly he didn't verify the HTML before he released the original version. ;-)
> >
> >Drives me mental as it produces lots a visual screw up when a certain
> >pattern in the form elements is created
>
> That's the joy of HTML errors - often the output will appear normal until you make some
> minor, and apparently irrelevant, change, when it all goes haywire.
>
>
That's not the only point. If you're on a slow connection you'll notice
the issue. Some browsers only start displaying the page once all the
layout data has been loaded. I've seen some sites with nesting levels of
7 tables deep sometimes, and that's just a mess. I'm also unsure how
text/speech/Braille browsers deal with complex table sites too.

And tables shouldn't be used for layout, use CSS instead!...

Thanks,
Ash
http://www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

as it comes to this point I can recomment an O'reilly book "High Performance
Web Sites, essential knowledge for frontend engineers"

if u read that book ur eyes will grow and u will not bother about php
comments,

ralph


"Ashley Sheridan" wrote in message
news:1249543712.3358.104.camel@localhost...
> On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> > On Wed, 5 Aug 2009 09:25:20 -0400, phpster@gmail.com (Bastien Koert)
wrote:
> >
> > >On Wed, Aug 5, 2009 at 8:02 AM, Ashley
Sheridan wrote:
> > >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> > >>> Thank you to all of you who have commented on this query.
> > >>>
> > >>> On the subject of comments, I feel that Larry Garfield settled this
query by pointing out
> > >>> that halving the size of a particular document gave a barely
noticeable increase in speed.
> > >>> Paul Foster pointed out the problem of maintenance, but if, as I do,
you do your
> > >>> development in-house, and then upload the working copies of the
program, it would be
> > >>> possible to strip out comments when you upload it. If you were
really paranoid, this could
> > >>> have the advantage that if somebody managed to steal your code from
the server it would be
> > >>> that much harder for them to understand. On the other hand the
process of stripping out
> > >>> the comments could potentially introduce new bugs, and I think this
consideration would
> > >>> outweigh anything else.
> > >>>
> > >>> I have recently come to the conclusion that I should never consider
anything completed
> > >>> until I have analysed the HTML code for an actual page. It is
amazing how badly mangled
> > >>> tables and the like can be without producing any visible effect on
the page, and on
> > >>> several occasions I have found PHP error messages which were mixed
up with the HTML in
> > >>> such a way that they were not displayed at all. On at least one
occasion this gave me the
> > >>> clue to an otherwise baffling bug.
> > >>>
> > >>> I have also discovered that the process of analysing the HTML is
made substantially
> > >>> simpler by inserting HTML comments into the output; e.g. instead of
> > >>>
> > >>> Echo '';
> > >>> write
> > >>> ?>
> > >>>
> > >>> > > >>>
> > >>>
> > >>> > > >>>
> > >>> Unfortunately, for HTML readability, it is highly desirable not to
indent the code, and if
> > >>> you are trying to have nicely indented braces, this makes the PHP
code that much harder to
> > >>> interpret.
> > >>>
> > >>> And on the question of functions there is some virtue (primarily
from the point of view of
> > >>> maintenance) in not having individual files too large, so while it
seems to be the general
> > >>> consensus that splitting up functions into groups to give smaller
files will probably slow
> > >>> things down a bit, if they can be grouped into sets which are only
loaded in particular
> > >>> circumstances this would be worth doing.
> > >>>
> > >>>
> > >> Nested tables are the devils playthings!
> >
> > I must be the devil, then. I enjoy playing with them. And if they're
done right they
> > seem to work on every system I have tried them on. Granted Dreamweaver
design mode gets
> > its knickers in a knot if you nest them more than about 4 deep.
> >
> > >>
> > >> Thanks,
> > >> Ash
> > >> http://www.ashleysheridan.co.uk
> > >>
> > >>
> > >> --
> > >> PHP General Mailing List (http://www.php.net/)
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> > >>
> > >
> > >I would agree there...we have an app that allows users to create forms
> > >dynamically with a left and right panel section along with some full
> > >width plug-in. At a minimum this is built with three nested tables.
> > >Here's the really rotten part, the VP (original dev for the display
> > >code) screwed a table close up somewhere. A bug they found literally
> > >minutes before it when to prod at a client site, instead of giving me
> > >15 minutes to trace it down, they wrapped the entire table structure
> > >in another table to make it look pretty.
> >
> > Clearly he didn't verify the HTML before he released the original
version. ;-)
> > >
> > >Drives me mental as it produces lots a visual screw up when a certain
> > >pattern in the form elements is created
> >
> > That's the joy of HTML errors - often the output will appear normal
until you make some
> > minor, and apparently irrelevant, change, when it all goes haywire.
> >
> >
> That's not the only point. If you're on a slow connection you'll notice
> the issue. Some browsers only start displaying the page once all the
> layout data has been loaded. I've seen some sites with nesting levels of
> 7 tables deep sometimes, and that's just a mess. I'm also unsure how
> text/speech/Braille browsers deal with complex table sites too.
>
> And tables shouldn't be used for layout, use CSS instead!...
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Thu, 2009-08-06 at 12:05 +0200, Ralph Deffke wrote:
> as it comes to this point I can recomment an O'reilly book "High Performance
> Web Sites, essential knowledge for frontend engineers"
>
> if u read that book ur eyes will grow and u will not bother about php
> comments,
>
> ralph
>
>
> "Ashley Sheridan" wrote in message
> news:1249543712.3358.104.camel@localhost...
> > On Thu, 2009-08-06 at 09:24 +1000, Clancy wrote:
> > > On Wed, 5 Aug 2009 09:25:20 -0400, phpster@gmail.com (Bastien Koert)
> wrote:
> > >
> > > >On Wed, Aug 5, 2009 at 8:02 AM, Ashley
> Sheridan wrote:
> > > >> On Wed, 2009-08-05 at 21:49 +1000, Clancy wrote:
> > > >>> Thank you to all of you who have commented on this query.
> > > >>>
> > > >>> On the subject of comments, I feel that Larry Garfield settled this
> query by pointing out
> > > >>> that halving the size of a particular document gave a barely
> noticeable increase in speed.
> > > >>> Paul Foster pointed out the problem of maintenance, but if, as I do,
> you do your
> > > >>> development in-house, and then upload the working copies of the
> program, it would be
> > > >>> possible to strip out comments when you upload it. If you were
> really paranoid, this could
> > > >>> have the advantage that if somebody managed to steal your code from
> the server it would be
> > > >>> that much harder for them to understand. On the other hand the
> process of stripping out
> > > >>> the comments could potentially introduce new bugs, and I think this
> consideration would
> > > >>> outweigh anything else.
> > > >>>
> > > >>> I have recently come to the conclusion that I should never consider
> anything completed
> > > >>> until I have analysed the HTML code for an actual page. It is
> amazing how badly mangled
> > > >>> tables and the like can be without producing any visible effect on
> the page, and on
> > > >>> several occasions I have found PHP error messages which were mixed
> up with the HTML in
> > > >>> such a way that they were not displayed at all. On at least one
> occasion this gave me the
> > > >>> clue to an otherwise baffling bug.
> > > >>>
> > > >>> I have also discovered that the process of analysing the HTML is
> made substantially
> > > >>> simpler by inserting HTML comments into the output; e.g. instead of
> > > >>>
> > > >>> Echo '';
> > > >>> write
> > > >>> ?>
> > > >>>
> > > >>> > > > >>>
> > > >>>
> > > >>> > > > >>>
> > > >>> Unfortunately, for HTML readability, it is highly desirable not to
> indent the code, and if
> > > >>> you are trying to have nicely indented braces, this makes the PHP
> code that much harder to
> > > >>> interpret.
> > > >>>
> > > >>> And on the question of functions there is some virtue (primarily
> from the point of view of
> > > >>> maintenance) in not having individual files too large, so while it
> seems to be the general
> > > >>> consensus that splitting up functions into groups to give smaller
> files will probably slow
> > > >>> things down a bit, if they can be grouped into sets which are only
> loaded in particular
> > > >>> circumstances this would be worth doing.
> > > >>>
> > > >>>
> > > >> Nested tables are the devils playthings!
> > >
> > > I must be the devil, then. I enjoy playing with them. And if they're
> done right they
> > > seem to work on every system I have tried them on. Granted Dreamweaver
> design mode gets
> > > its knickers in a knot if you nest them more than about 4 deep.
> > >
> > > >>
> > > >> Thanks,
> > > >> Ash
> > > >> http://www.ashleysheridan.co.uk
> > > >>
> > > >>
> > > >> --
> > > >> PHP General Mailing List (http://www.php.net/)
> > > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > > >>
> > > >>
> > > >
> > > >I would agree there...we have an app that allows users to create forms
> > > >dynamically with a left and right panel section along with some full
> > > >width plug-in. At a minimum this is built with three nested tables.
> > > >Here's the really rotten part, the VP (original dev for the display
> > > >code) screwed a table close up somewhere. A bug they found literally
> > > >minutes before it when to prod at a client site, instead of giving me
> > > >15 minutes to trace it down, they wrapped the entire table structure
> > > >in another table to make it look pretty.
> > >
> > > Clearly he didn't verify the HTML before he released the original
> version. ;-)
> > > >
> > > >Drives me mental as it produces lots a visual screw up when a certain
> > > >pattern in the form elements is created
> > >
> > > That's the joy of HTML errors - often the output will appear normal
> until you make some
> > > minor, and apparently irrelevant, change, when it all goes haywire.
> > >
> > >
> > That's not the only point. If you're on a slow connection you'll notice
> > the issue. Some browsers only start displaying the page once all the
> > layout data has been loaded. I've seen some sites with nesting levels of
> > 7 tables deep sometimes, and that's just a mess. I'm also unsure how
> > text/speech/Braille browsers deal with complex table sites too.
> >
> > And tables shouldn't be used for layout, use CSS instead!...
> >
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
> >
>
>
>
Are you seriously suggesting one shouldn't comment their PHP code?!

Thanks,
Ash
http://www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Thu, 06 Aug 2009 08:28:32 +0100, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:

........
>> >> Nested tables are the devils playthings!
>>
>> I must be the devil, then. I enjoy playing with them. And if they're done right they
>> seem to work on every system I have tried them on. Granted Dreamweaver design mode gets
>> its knickers in a knot if you nest them more than about 4 deep.
>>
............
>>
>> That's the joy of HTML errors - often the output will appear normal until you make some
>> minor, and apparently irrelevant, change, when it all goes haywire.
>>
>>
>That's not the only point. If you're on a slow connection you'll notice
>the issue. Some browsers only start displaying the page once all the
>layout data has been loaded. I've seen some sites with nesting levels of
>7 tables deep sometimes, and that's just a mess. I'm also unsure how
>text/speech/Braille browsers deal with complex table sites too.

I once watched a blind man go through one of my sites. I was apprehensive because I had no
made no attempt to achieve compatibility, and had not bothered with any alt = ''
declarations. The images were all in their own tables, and they all had titles, and he
said that because of this the site was relatively good.
>
>And tables shouldn't be used for layout, use CSS instead!...

I was talking to another web designer last night. He started life as a designer, and said
that he liked CSS because it was written by designers. On the other hand I started life
as a programmer (well I really started life as an engineer), and I find CSS hard to
understand, and harder to write. I can readily produce what I want with tables, but I
have no idea how I could achieve many of the results I get with CSS alone.

How, for example, could I otherwise achieved the following effect, which displays an image
with a border slightly darker than the background, and with the title and subtitle inside
the border?

Yanni Nxxxxx Sally Riordan Scholarship, 2007-

Re: Re: PHP programming strategy

On Fri, 2009-08-07 at 11:06 +1000, Clancy wrote:
> On Thu, 06 Aug 2009 08:28:32 +0100, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:
>
> .......
> >> >> Nested tables are the devils playthings!
> >>
> >> I must be the devil, then. I enjoy playing with them. And if they're done right they
> >> seem to work on every system I have tried them on. Granted Dreamweaver design mode gets
> >> its knickers in a knot if you nest them more than about 4 deep.
> >>
> ...........
> >>
> >> That's the joy of HTML errors - often the output will appear normal until you make some
> >> minor, and apparently irrelevant, change, when it all goes haywire.
> >>
> >>
> >That's not the only point. If you're on a slow connection you'll notice
> >the issue. Some browsers only start displaying the page once all the
> >layout data has been loaded. I've seen some sites with nesting levels of
> >7 tables deep sometimes, and that's just a mess. I'm also unsure how
> >text/speech/Braille browsers deal with complex table sites too.
>
> I once watched a blind man go through one of my sites. I was apprehensive because I had no
> made no attempt to achieve compatibility, and had not bothered with any alt = ''
> declarations. The images were all in their own tables, and they all had titles, and he
> said that because of this the site was relatively good.
> >
> >And tables shouldn't be used for layout, use CSS instead!...
>
> I was talking to another web designer last night. He started life as a designer, and said
> that he liked CSS because it was written by designers. On the other hand I started life
> as a programmer (well I really started life as an engineer), and I find CSS hard to
> understand, and harder to write. I can readily produce what I want with tables, but I
> have no idea how I could achieve many of the results I get with CSS alone.
>
> How, for example, could I otherwise achieved the following effect, which displays an image
> with a border slightly darker than the background, and with the title and subtitle inside
> the border?
>
>

> > Yanni Nxxxxx > Sally Riordan Scholarship, 2007- >

Yanni Nxxxxx

Sally Riordan Scholarship, 2007-

Re: Re: PHP programming strategy

On Fri, 07 Aug 2009 06:32:48 +0100, ash@ashleysheridan.co.uk (Ashley Sheridan) wrote:
........
>> How, for example, could I otherwise achieved the following effect, which displays an image
>> with a border slightly darker than the background, and with the title and subtitle inside
>> the border?
>>
>>

>> >> Yanni Nxxxxx >> Sally Riordan Scholarship, 2007- >>

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

Re: Re: PHP programming strategy

At 6:32 AM +0100 8/7/09, Ashley Sheridan wrote:
>
> >

>> >> Yanni Nxxxxx >> Sally Riordan Scholarship, 2007- >>

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

Yanni Nxxxxx

Sally Riordan Scholarship, 2007-

Yanni Nxxxxx

Sally Riordan Scholarship, 2007-

Re: Re: PHP programming strategy

On Sat, 2009-08-08 at 07:53 -0400, tedd wrote:
> At 6:32 AM +0100 8/7/09, Ashley Sheridan wrote:
> >
> > >

> >> > >> Yanni Nxxxxx > >> Sally Riordan Scholarship, 2007- > >>

> >
> >

Yanni Nxxxxx

> >

Sally Riordan Scholarship, 2007-

> >

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

Re: Re: PHP programming strategy

On Sat, 8 Aug 2009 07:53:42 -0400, tedd.sperling@gmail.com (tedd) wrote:
.....
>You don't need the width="210" height="300". For example, this works:
>
>

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

has normal paragraph spacing, 'nrmltxtn' has zero spacing, and
'notetxtn' is a size smaller, also with zero line spacing.

>Also, if you use first-child, it could be taken down to:
>
>

>
>

Yanni Nxxxxx

>

Sally Riordan Scholarship, 2007-

>

has normal
paragraph spacing, 'nrmltxtn' has zero spacing, and 'notetxtn' is a size smaller, also
with zero line spacing.

I could redefine

&

for this class (provided I never want to use the normal values
in it), but there is something to be said for having a standard set of fonts, and always
knowing what I will get, rather than having

mean something different every time I use
it.

And, as others have pointed out, a few thousand bytes more or less is totally immaterial.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

At 10:54 AM +1000 8/9/09, Clancy wrote:
>On Sat, 8 Aug 2009 07:53:42 -0400, tedd.sperling@gmail.com (tedd) wrote:
> >Also, if you use first-child, it could be taken down to:
>>
>>

>>
>>

Yanni Nxxxxx

>>

Sally Riordan Scholarship, 2007-

>>

has normal
>paragraph spacing, 'nrmltxtn' has zero spacing, and 'notetxtn' is a
>size smaller, also
>with zero line spacing.
>

Yes, but using first-child you can make the first child

of class
"pfm" whatever you want while making all other children

's in the
class something else.

But, as it was said, IE's have problems with first-child rules.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Sun, 2009-08-09 at 07:55 -0400, tedd wrote:
> At 10:54 AM +1000 8/9/09, Clancy wrote:
> >On Sat, 8 Aug 2009 07:53:42 -0400, tedd.sperling@gmail.com (tedd) wrote:
> > >Also, if you use first-child, it could be taken down to:
> >>
> >>

> >>
> >>

Yanni Nxxxxx

> >>

Sally Riordan Scholarship, 2007-

> >>

has normal
> >paragraph spacing, 'nrmltxtn' has zero spacing, and 'notetxtn' is a
> >size smaller, also
> >with zero line spacing.
> >
>
> Yes, but using first-child you can make the first child

of class
> "pfm" whatever you want while making all other children

's in the
> class something else.
>
> But, as it was said, IE's have problems with first-child rules.
>
> Cheers,
>
> tedd
>
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
How does IE8 fare with selectors in CSS?

Thanks,
Ash
http://www.ashleysheridan.co.uk


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

At 1:05 PM +0100 8/9/09, Ashley Sheridan wrote:
>On Sun, 2009-08-09 at 07:55 -0400, tedd wrote:
>
> > But, as it was said, IE's have problems with first-child rules.
>>
>
>How does IE8 fare with selectors in CSS?
>
>Thanks,
>Ash

tedd = clue--

or

tedd < clue

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: PHP programming strategy

On Sun, Aug 9, 2009 at 6:33 PM, tedd wrote:
> At 1:05 PM +0100 8/9/09, Ashley Sheridan wrote:
>>
>> On Sun, 2009-08-09 at 07:55 -0400, tedd wrote:
>>
>>  > But, as it was said, IE's have problems with first-child rules.
>>>
>>
>> How does IE8 fare with selectors in CSS?
>>
>> Thanks,
>> Ash
>
> tedd =3D clue--
>
> or
>
> tedd < clue
>
> tedd
>
> --
> -------
> http://sperling.com  http://ancientstones.com  http://earthston=
es.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

IE8 is the most CSS2 standards compliant browser, if I recall they
submitted 5 or 6 dozen tests to the w3c that they were the only
browser that passed. As far as selectors go:
http://msdn.microsoft.com/en-us/library/cc351024%28VS.85%29. aspx#selectors
looks to me like they're fully compliant with CSS2.1.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php