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> >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! 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
