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<ash@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. > > 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