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

>On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan<a...@ashleysheridan.co.uk> 
>> 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 '</td></tr></table></td></tr></table>';
>>> write
>>> ?>
>>> </td></tr></table>
>>> <!-End of table 2 '
>>> </td></tr></table>
>>> <!-End of table 1 '
>>> 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

Reply via email to