Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #4653 > unrolled thread

php+html mixup in displaying multidimensional array in html tables

Back to article view | Back to comp.lang.php

Contents

  php+html mixup in displaying multidimensional array in html tables John <John@agdp.de> - 2012-01-28 12:24 +0100
    Re: php+html mixup in displaying multidimensional array in html tables Luuk <Luuk@invalid.lan> - 2012-01-28 13:03 +0100
    Re: php+html mixup in displaying multidimensional array in html tables crankypuss <no@email.thanks> - 2012-01-28 05:07 -0700
    Re: php+html mixup in displaying multidimensional array in html tables Denis McMahon <denismfmcmahon@gmail.com> - 2012-01-28 19:28 +0000
      Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-28 15:14 -0500
        Re: php+html mixup in displaying multidimensional array in html tables Denis McMahon <denismfmcmahon@gmail.com> - 2012-01-29 19:58 +0000
          Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-29 15:09 -0500
            Re: php+html mixup in displaying multidimensional array in html tables Denis McMahon <denismfmcmahon@gmail.com> - 2012-01-29 22:10 +0000
              Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-29 17:41 -0500
      Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-28 22:01 +0100
        Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-28 17:37 -0500
        Re: php+html mixup in displaying multidimensional array in html tables Michael Fesser <netizen@gmx.de> - 2012-01-29 00:02 +0100
          Re: php+html mixup in displaying multidimensional array in html tables The Natural Philosopher <tnp@invalid.invalid> - 2012-01-28 23:08 +0000
    Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-28 21:43 +0100
    Re: php+html mixup in displaying multidimensional array in html tables "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2012-01-29 00:50 +0100
      Re: php+html mixup in displaying multidimensional array in html tables r.mariotti@fdcx.net - 2012-01-29 06:55 -0500
        Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-29 15:43 +0100
          Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-29 10:44 -0500
            Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-29 17:15 +0100
              Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-29 11:45 -0500
                Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-29 18:41 +0100
                  Re: php+html mixup in displaying multidimensional array in html tables Jerry Stuckle <jstucklex@attglobal.net> - 2012-01-29 13:49 -0500
                  Re: php+html mixup in displaying multidimensional array in html tables Scott Johnson <noonehome@chalupasworld.com> - 2012-01-30 06:04 -0800
                    Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-30 16:03 +0100
          Re: php+html mixup in displaying multidimensional array in html tables Scott Johnson <noonehome@chalupasworld.com> - 2012-01-30 05:51 -0800
            Re: php+html mixup in displaying multidimensional array in html tables Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-01-30 16:27 +0100

Page 2 of 2 — ← Prev page 1 [2]

#4675

Jerry Stuckle wrote:

> On 1/29/2012 11:15 AM, Thomas 'PointedEars' Lahn wrote:
>> Jerry Stuckle wrote:
>>> On 1/29/2012 9: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<<<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.
>>> What does indenting have to do with it?  And an HTML validator will
>>> definitely see ALL the HTML you put out - because it is sent to the
>>> client.
>> You can't read, can you?
> 
> A whole lot better than you, obviously.  But then you one again have
> shown you have no idea what you're talking about.

No, evidently you can't read.  For if you could, you would have noticed that 
indenting heredoc inevitably shifts the delimiter right from the first 
column, which creates a *syntax error*; so with heredoc you have to take 
extra care that you do not indent that line, which makes maintenance harder.  
You also have to take extra care then that the character following the 
delimiter is at most one `;'; for example, concatenation is only possible 
with the dot at the *next* line.  All of that jumping through hoops for 
gaining program *inefficiency* is unnecessary if one uses the natural, 
efficient way of PHP coding with multiple PHP sections in the first place 
(with the alternative syntax if you prefer that).

And if you could also think clearly, you would have interpreted "client-side 
validate" as a validation *before* the PHP source code is deployed on the 
production server, in the source code editor, and not misconstrued it as 
validation in the browser (which is not even possible in all browsers).

Nuff said.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [next] | [standalone]

#4676

On 1/29/2012 12:41 PM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 1/29/2012 11:15 AM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 1/29/2012 9: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<<<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.
>>>> What does indenting have to do with it?  And an HTML validator will
>>>> definitely see ALL the HTML you put out - because it is sent to the
>>>> client.
>>> You can't read, can you?
>>
>> A whole lot better than you, obviously.  But then you one again have
>> shown you have no idea what you're talking about.
>
> No, evidently you can't read.  For if you could, you would have noticed that
> indenting heredoc inevitably shifts the delimiter right from the first
> column, which creates a *syntax error*; so with heredoc you have to take
> extra care that you do not indent that line, which makes maintenance harder.
> You also have to take extra care then that the character following the
> delimiter is at most one `;'; for example, concatenation is only possible
> with the dot at the *next* line.  All of that jumping through hoops for
> gaining program *inefficiency* is unnecessary if one uses the natural,
> efficient way of PHP coding with multiple PHP sections in the first place
> (with the alternative syntax if you prefer that).
>

Sure, and you have to have the test for an 'if' statement enclosed in 
parentheses, and variable names must start with a '$' - and all kinds of 
things.  That's the syntax.  But it is not less efficient - in fact, it 
is much MORE efficient than your way of going in and out of PHP.  The 
text in the HEREDOC is parsed ONCE - when the entire script is parsed 
(which must be done anyway).  But you're in PHP and you stay in PHP. 
Multiple sections are not "natural" nor efficient.

> And if you could also think clearly, you would have interpreted "client-side
> validate" as a validation *before* the PHP source code is deployed on the
> production server, in the source code editor, and not misconstrued it as
> validation in the browser (which is not even possible in all browsers).
>

You can't client-side validate before the PHP source code is deployed on 
the server.  Validating in a context-sensitive editor is much different 
- but then you obviously don't understand that difference, either.

> Nuff said.
>
>
> PointedEars

I would suggest that is a good idea.  You just continue show your 
stoopidity and complete lack of understanding of basic PHP programming.

But you continue to do that in other newsgroups, also.  So that's 
nothing new.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#4684

On 1/29/2012 9:41 AM, Thomas 'PointedEars' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 1/29/2012 11:15 AM, Thomas 'PointedEars' Lahn wrote:
>>> Jerry Stuckle wrote:
>>>> On 1/29/2012 9: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<<<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.
>>>> What does indenting have to do with it?  And an HTML validator will
>>>> definitely see ALL the HTML you put out - because it is sent to the
>>>> client.
>>> You can't read, can you?
>>
>> A whole lot better than you, obviously.  But then you one again have
>> shown you have no idea what you're talking about.
>
> No, evidently you can't read.  For if you could, you would have noticed that
> indenting heredoc inevitably shifts the delimiter right from the first
> column, which creates a *syntax error*; so with heredoc you have to take
> extra care that you do not indent that line, which makes maintenance harder.
> You also have to take extra care then that the character following the
> delimiter is at most one `;'; for example, concatenation is only possible
> with the dot at the *next* line.  All of that jumping through hoops for
> gaining program *inefficiency* is unnecessary if one uses the natural,
> efficient way of PHP coding with multiple PHP sections in the first place
> (with the alternative syntax if you prefer that).
>
> And if you could also think clearly, you would have interpreted "client-side
> validate" as a validation *before* the PHP source code is deployed on the
> production server, in the source code editor, and not misconstrued it as
> validation in the browser (which is not even possible in all browsers).
>

OK maybe I am not thinking clearly here but trying to wrap my head 
around what you mean by "validation before the php source code is 
deployed on the production server".  The only thing I can guess is that 
you are meaning using you editor to validate your code structure?

Please enlighten.

> Nuff said.

Nina Simone? Is that you?

>
>
> PointedEars

[toc] | [prev] | [next] | [standalone]

#4685

Scott Johnson wrote:

> […] trying to wrap my head around what you mean by "validation before the
> php source code is deployed on the production server".  The only thing I
> can guess is that you are meaning using you editor to validate your code
> structure?

That is correct.  For example, Eclipse PHP Development Tools (PDT) [1] allow 
you to perform validation both on the PHP code *and* the content that is 
being generated with PHP if the latter is generated outside of PHP sections.  
It is also properly highlighted then, and the structure is displayed in the 
Outline View (where you can switch between the PHP parse tree and the 
markup/whatever parse tree).

This is very helpful, especially if you need to generate content with a 
complex structure (e. g. in templates).  It appears to work with any 
generated content, as long as the filename suffix is .php or you have added 
the Content-Type to the list of PHP types and opened the file with the PHP 
Editor.  (This also works with temporary files downloaded from the 
production server for a quick fix to be backported later.)

Apparently that client-side validation is not as common a technique among 
PHP developers as I thought.  However, this would account for the amount of 
markup ranging from being slightly invalid to completely borken, working 
only by chance because of browser's error correction, that is generated by 
many PHP-driven Web applications.


PointedEars
___________
[1] <http://www.eclipse.org/projects/project.php?id=tools.pdt>
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#4683

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<<<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.
The browser has no idea how the info sent to it was created, only that 
it is sent in proper context.

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

> <http://php.net/manual/en/language.types.string.php#language.types.string.syntax.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.

>
> PointedEars

[toc] | [prev] | [next] | [standalone]

#4686

Scott Johnson wrote:

> 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<<<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.syntax.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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.php

csiph-web