On Wed, Aug 5, 2009 at 8:02 AM, Ashley Sheridan<ash@xxxxxxxxxxxxxxxxxxxx> 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 '</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! > > 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 -- Bastien Cat, the other other white meat -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
