Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!usenet-fr.net!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="ISO-8859-1" Message-ID: <1401819.V9SEqChMir@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Mon, 30 Jan 2012 16:27:32 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 7Bit Subject: Re: php+html mixup in displaying multidimensional array in html tables Newsgroups: comp.lang.php References: <9ojfv3Fhu4U1@mid.uni-berlin.de> <5854644.bgypaU67uL@PointedEars.de> Followup-To: comp.lang.php MIME-Version: 1.0 Lines: 87 NNTP-Posting-Date: 30 Jan 2012 16:27:33 CET NNTP-Posting-Host: 01b43349.newsspool1.arcor-online.net X-Trace: DXC=7FSBacROhIEWDmlTRbh@=Iic==]BZ:afN4Fo<]lROoRA<`=YMgDjhgBD^`i3[Q On 1/29/2012 6:43 AM, Thomas 'PointedEars' Lahn wrote: >> r.mariotti@fdcx.net wrote: >>> After developing numerus commercial sites over the past decade+ all >>> the php I've created is by far mostly procedural. I personally never >>> leave php and output my pages with a "print<<>> page follows, variaables embededded and all. >>> Easy to create, read, follow, maintain, etc. >> >> Except when you want to indent or client-side validate your code. As for >> the former, the EOD (or whatever delimiter you use) must be at the >> *beginning of the line* and must at most followed by `;'. As for the >> latter, a client-side HTML validator will not see the HTML that you put >> out because to it it is PHP. > > I use heredocs for all my forms (particularly admin) and have no issues > with client side functions on the form even ajax work flawlessly. I did not mean that. > The browser has no idea how the info sent to it was created, only that > it is sent in proper context. Of course. >> In addition, you still would have string escaping issues and difficulties >> with function calls, and it is very inefficient to have PHP string-parse >> large chunks of code that does not need parsing in the first place. > > I actually find using strings in heredocs is very easy. Instead of > having to escape with my typical " . $var . " now all I need is {$var} > which seems to me as more of an easier and 'template' type of design to > read. > > There are times when I need to call a method inside of the heredoc in > which case I process that var in a call above the heredoc definition. ACK. The drawback of that approach is that you have a variable definition that is detached from the context in which the variable is used; the larger the heredoc, the more detached. This counts as "jumping through hoops" in my book, as in "lacking flexibility". >> >> >> BTDT. Here-doc is tempting as a solution to this problem, but in the >> long run it is more trouble than it is worth. > > I have the opposite opinion once I started to use it more often. > It is simple and easy to read part of the coding for me. For example, I have a CSS that is being generated by PHP because I am using PHP variables in it to ease maintenance. I would not think of using one large `echo' statement with heredoc to generate that stylesheet instead. Instead, I have several few *small* PHP sections in it which define the variable value and print it (with `echo'): [symlinked for you; the original has still suffix .css because of $ cat .htaccess SetHandler application/x-httpd-php ] So I let PHP only do what PHP must do, and can keep my variable definitions close to where I use them (but I do not have to). If I open the foo.css file with the CSS Editor, I can still use the Outline View to jump to the ruleset that concerns me and make the necessary modifications really fast, without having to think about escaping the whole stylesheet and related problems. This approach is very flexible and very efficient in several ways. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee