| Re: php+html mixup in displaying multidimensional array in html tables [message #176873 is a reply to message #176870] |
Mon, 30 January 2012 15:27  |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
|
Senior Member |
|
|
Scott Johnson wrote:
> On 1/29/2012 6:43 AM, Thomas 'PointedEars' Lahn wrote:
>> r(dot)mariotti(at)fdcx(dot)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<<<EOD" and the entire
>>> 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".
>>
< http://php.net/manual/en/language.types.string.php#language.types.string.sy ntax.heredoc>
>>
>> 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'):
<http://PointedEars.de/media/video/series/style.css.phps>
[symlinked for you; the original has still suffix .css because of
$ cat .htaccess
<IfModule mod_php5.c>
<FilesMatch "\.(ph(p3?|tml)|css)$">
SetHandler application/x-httpd-php
</FilesMatch>
</IfModule>
]
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]