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

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

PHP CSV

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

Contents

  PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 17:09 +0530
    Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 13:11 +0100
      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 13:27 +0100
        Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:26 +0530
          Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 14:43 +0100
            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 09:24 -0500
            Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 20:56 +0530
              Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 16:57 +0100
                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 17:04 +0100
                Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 21:52 +0530
                  Re: PHP CSV Markus Heinz <markus.heinz@uni-dortmund.de> - 2014-12-18 17:38 +0100
                    Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 16:49 +0000
                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 21:34 -0500
                    Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2014-12-19 09:43 +0000
                      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-19 14:05 +0100
                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-19 10:59 -0500
                          Re: PHP CSV Matthew Carter <m@ahungry.com> - 2014-12-19 14:21 -0500
                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-19 18:17 -0500
                            Re: PHP CSV "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2014-12-20 00:35 +0100
                          Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 13:19 +0100
                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 08:03 -0500
                              Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 13:29 +0000
                                Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 09:06 -0500
                                  Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 15:26 +0000
                                    Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 10:40 -0500
                                      Re: PHP CSV Paul Herber <paul@pherber.com> - 2015-02-04 16:11 +0000
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 11:23 -0500
                                          Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 17:08 +0000
                                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:48 -0500
                                      Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 17:05 +0000
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:49 -0500
                                          Re: PHP CSV Tim Streater <timstreater@greenbee.net> - 2015-02-04 18:14 +0000
                                            Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 13:37 -0500
                                              Re: PHP CSV Matthew Carter <m@ahungry.com> - 2015-02-04 15:23 -0500
                                                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-04 21:54 +0100
                                                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 16:32 -0500
                                                Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 16:31 -0500
                                  Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 16:39 +0100
                                    Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 10:57 -0500
                                      Re: PHP CSV Erwin Moller <erwinmollerusenet@xs4all.nl> - 2015-02-04 18:07 +0100
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-04 12:55 -0500
                                    Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-06 23:26 +0100
                                      Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 01:38 +0100
                                        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-06 19:44 -0500
                                          Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:49 +0100
                                        Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-07 14:28 +0100
                                      Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-06 19:42 -0500
                                        Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 04:33 +0100
                                          Re: PHP CSV Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-07 14:26 +0100
                                            Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:45 +0100
                                              Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 08:54 -0500
                                                Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 16:54 +0100
                                                  Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 11:00 -0500
                                          Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 08:51 -0500
                                            Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 14:55 +0100
          Re: PHP CSV Olaf Schmitt <thesys@gmx.de> - 2014-12-19 01:16 +0100
          Re: PHP CSV Denis McMahon <denismfmcmahon@gmail.com> - 2014-12-19 02:14 +0000
      Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:13 +0530
        Re: PHP CSV Derek Turner <frderek@cesmail.net> - 2014-12-18 12:55 +0000
          Re: PHP CSV Joydeep Chakrabarty <chalao.adda@gmail.com> - 2014-12-18 18:33 +0530
            Re: PHP CSV Derek Turner <frderek@cesmail.net> - 2014-12-18 13:10 +0000
        Re: PHP CSV Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-18 08:17 -0500
        Re: PHP CSV "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-12-18 15:16 +0100

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#14856

On 2/4/2015 7:19 AM, Erwin Moller wrote:
> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
> 
> <snip>
>>
>> return does not create invalid output.  die() and exit() do.
>>
>> I have *never* found a need for either one in a properly constructed
>> script.
>>
> 
> I use exit() after a header location combi.
> 
> if (whatever){
>     dostuff();
>     header("location: ....");
>     exit;
> }
> 
> It is an easy way to redirect, and terminate the script, and not having
> a (possibly huge) else-part.
> 
> Do you (Jerry) think that that approach isn't properly?
> If so, why?
> 
> 
> Regards,
> Erwin Moller
> 

With a properly constructed script, you don't need to call exit() after
a header() call, either.



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

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

#14857

In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/4/2015 7:19 AM, Erwin Moller wrote:
>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:

>>> return does not create invalid output.  die() and exit() do.
>>>
>>> I have *never* found a need for either one in a properly constructed
>>> script.

>> I use exit() after a header location combi.
>> 
>> if (whatever){
>>     dostuff();
>>     header("location: ....");
>>     exit;
>> }
>> 
>> It is an easy way to redirect, and terminate the script, and not having
>> a (possibly huge) else-part.
>> 
>> Do you (Jerry) think that that approach isn't properly?
>> If so, why?

>With a properly constructed script, you don't need to call exit() after
>a header() call, either.

I use exit when processing is complete. Sometimes that happens inside
an "if" or other construct.

I certainly don't intend, ever, to use convoluted if/then/else just so
that processing always arrives at the last line of a script.

-- 
"I love the way that Microsoft follows standards. 
 In much the same manner as fish follow migrating caribou."
                                               - Paul Tomblin, ASR

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

#14858

On 2/4/2015 8:29 AM, Tim Streater wrote:
> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
> 
>>>> return does not create invalid output.  die() and exit() do.
>>>>
>>>> I have *never* found a need for either one in a properly constructed
>>>> script.
> 
>>> I use exit() after a header location combi.
>>>
>>> if (whatever){
>>>     dostuff();
>>>     header("location: ....");
>>>     exit;
>>> }
>>>
>>> It is an easy way to redirect, and terminate the script, and not having
>>> a (possibly huge) else-part.
>>>
>>> Do you (Jerry) think that that approach isn't properly?
>>> If so, why?
> 
>> With a properly constructed script, you don't need to call exit() after
>> a header() call, either.
> 
> I use exit when processing is complete. Sometimes that happens inside
> an "if" or other construct.
> 
> I certainly don't intend, ever, to use convoluted if/then/else just so
> that processing always arrives at the last line of a script.
> 

Which terminates processing immediately - and anything after that point
(such as </BODY> and </HTML> tags is not sent to the browser.  This
causes an invalid page to be generated.

Do your clients know you're generating invalid HTML for them?

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

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

#14859

In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/4/2015 8:29 AM, Tim Streater wrote:
>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>> 
>>>>> return does not create invalid output.  die() and exit() do.
>>>>>
>>>>> I have *never* found a need for either one in a properly constructed
>>>>> script.
>> 
>>>> I use exit() after a header location combi.
>>>>
>>>> if (whatever){
>>>>     dostuff();
>>>>     header("location: ....");
>>>>     exit;
>>>> }
>>>>
>>>> It is an easy way to redirect, and terminate the script, and not having
>>>> a (possibly huge) else-part.
>>>>
>>>> Do you (Jerry) think that that approach isn't properly?
>>>> If so, why?
>> 
>>> With a properly constructed script, you don't need to call exit() after
>>> a header() call, either.
>> 
>> I use exit when processing is complete. Sometimes that happens inside
>> an "if" or other construct.
>> 
>> I certainly don't intend, ever, to use convoluted if/then/else just so
>> that processing always arrives at the last line of a script.

>Which terminates processing immediately - and anything after that point
>(such as </BODY> and </HTML> tags is not sent to the browser.  This
>causes an invalid page to be generated.
>
>Do your clients know you're generating invalid HTML for them?

My scripts don't generate HTML. They generate data, which is
interpreted client-side and used to update what is presented to the
user.

-- 
"A committee is a cul-de-sac down which ideas are lured and then 
 quietly strangled." - Sir Barnett Cocks (1907-1989)

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

#14861

On 2/4/2015 10:26 AM, Tim Streater wrote:
> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>>
>>>>>> return does not create invalid output.  die() and exit() do.
>>>>>>
>>>>>> I have *never* found a need for either one in a properly constructed
>>>>>> script.
>>>
>>>>> I use exit() after a header location combi.
>>>>>
>>>>> if (whatever){
>>>>>     dostuff();
>>>>>     header("location: ....");
>>>>>     exit;
>>>>> }
>>>>>
>>>>> It is an easy way to redirect, and terminate the script, and not
>>>>> having
>>>>> a (possibly huge) else-part.
>>>>>
>>>>> Do you (Jerry) think that that approach isn't properly?
>>>>> If so, why?
>>>
>>>> With a properly constructed script, you don't need to call exit() after
>>>> a header() call, either.
>>>
>>> I use exit when processing is complete. Sometimes that happens inside
>>> an "if" or other construct.
>>>
>>> I certainly don't intend, ever, to use convoluted if/then/else just so
>>> that processing always arrives at the last line of a script.
> 
>> Which terminates processing immediately - and anything after that point
>> (such as </BODY> and </HTML> tags is not sent to the browser.  This
>> causes an invalid page to be generated.
>>
>> Do your clients know you're generating invalid HTML for them?
> 
> My scripts don't generate HTML. They generate data, which is
> interpreted client-side and used to update what is presented to the
> user.
> 

So you use some convoluted method of sending data to a client and having
something run on the client to interpret and display it?

Rather than simply generating HTML on the server and sending it to the
client, like the rest of the world does?

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

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

#14863

On Wed, 04 Feb 2015 10:40:50 -0500, Jerry Stuckle <jstucklex@attglobal.net> wrote:

>On 2/4/2015 10:26 AM, Tim Streater wrote:
>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>>>
>>>>>>> return does not create invalid output.  die() and exit() do.
>>>>>>>
>>>>>>> I have *never* found a need for either one in a properly constructed
>>>>>>> script.
>>>>
>>>>>> I use exit() after a header location combi.
>>>>>>
>>>>>> if (whatever){
>>>>>>     dostuff();
>>>>>>     header("location: ....");
>>>>>>     exit;
>>>>>> }
>>>>>>
>>>>>> It is an easy way to redirect, and terminate the script, and not
>>>>>> having
>>>>>> a (possibly huge) else-part.
>>>>>>
>>>>>> Do you (Jerry) think that that approach isn't properly?
>>>>>> If so, why?
>>>>
>>>>> With a properly constructed script, you don't need to call exit() after
>>>>> a header() call, either.
>>>>
>>>> I use exit when processing is complete. Sometimes that happens inside
>>>> an "if" or other construct.
>>>>
>>>> I certainly don't intend, ever, to use convoluted if/then/else just so
>>>> that processing always arrives at the last line of a script.
>> 
>>> Which terminates processing immediately - and anything after that point
>>> (such as </BODY> and </HTML> tags is not sent to the browser.  This
>>> causes an invalid page to be generated.
>>>
>>> Do your clients know you're generating invalid HTML for them?
>> 
>> My scripts don't generate HTML. They generate data, which is
>> interpreted client-side and used to update what is presented to the
>> user.
>> 
>
>So you use some convoluted method of sending data to a client and having
>something run on the client to interpret and display it?
>
>Rather than simply generating HTML on the server and sending it to the
>client, like the rest of the world does?

That is one of the worst misinterpretations of what might be happening that I've seen you
do. The data being sent could be all sorts of things. The script could be updating a
database. Nothing says that any HTML has to be generated.



-- 
Regards, Paul Herber, Sandrila Ltd.
http://www.sandrila.co.uk/
      

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

#14864

On 2/4/2015 11:11 AM, Paul Herber wrote:
> On Wed, 04 Feb 2015 10:40:50 -0500, Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>>> <jstucklex@attglobal.net> wrote:
>>>>>
>>>>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>>>>
>>>>>>>> return does not create invalid output.  die() and exit() do.
>>>>>>>>
>>>>>>>> I have *never* found a need for either one in a properly constructed
>>>>>>>> script.
>>>>>
>>>>>>> I use exit() after a header location combi.
>>>>>>>
>>>>>>> if (whatever){
>>>>>>>     dostuff();
>>>>>>>     header("location: ....");
>>>>>>>     exit;
>>>>>>> }
>>>>>>>
>>>>>>> It is an easy way to redirect, and terminate the script, and not
>>>>>>> having
>>>>>>> a (possibly huge) else-part.
>>>>>>>
>>>>>>> Do you (Jerry) think that that approach isn't properly?
>>>>>>> If so, why?
>>>>>
>>>>>> With a properly constructed script, you don't need to call exit() after
>>>>>> a header() call, either.
>>>>>
>>>>> I use exit when processing is complete. Sometimes that happens inside
>>>>> an "if" or other construct.
>>>>>
>>>>> I certainly don't intend, ever, to use convoluted if/then/else just so
>>>>> that processing always arrives at the last line of a script.
>>>
>>>> Which terminates processing immediately - and anything after that point
>>>> (such as </BODY> and </HTML> tags is not sent to the browser.  This
>>>> causes an invalid page to be generated.
>>>>
>>>> Do your clients know you're generating invalid HTML for them?
>>>
>>> My scripts don't generate HTML. They generate data, which is
>>> interpreted client-side and used to update what is presented to the
>>> user.
>>>
>>
>> So you use some convoluted method of sending data to a client and having
>> something run on the client to interpret and display it?
>>
>> Rather than simply generating HTML on the server and sending it to the
>> client, like the rest of the world does?
> 
> That is one of the worst misinterpretations of what might be happening that I've seen you
> do. The data being sent could be all sorts of things. The script could be updating a
> database. Nothing says that any HTML has to be generated.
> 
> 
> 

Paul, we are talking web pages here - not CLI scripts.

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

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

#14867

In article <math1o$d7a$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 4/2/2015 11:11, Paul Herber wrote:

>> That is one of the worst misinterpretations of what might be happening that
>> I've seen you do. The data being sent could be all sorts of things. The
>> script could be updating a database. Nothing says that any HTML has
>> to be generated.

>Paul, we are talking web pages here - not CLI scripts.

I'm not. I'm talking about using exit in the middle of a script.

-- 
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

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

#14868

On 2/4/2015 12:08 PM, Tim Streater wrote:
> In article <math1o$d7a$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 4/2/2015 11:11, Paul Herber wrote:
> 
>>> That is one of the worst misinterpretations of what might be
>>> happening that
>>> I've seen you do. The data being sent could be all sorts of things. The
>>> script could be updating a database. Nothing says that any HTML has
>>> to be generated.
> 
>> Paul, we are talking web pages here - not CLI scripts.
> 
> I'm not. I'm talking about using exit in the middle of a script.
> 

This whole conversation - until you - has been about web pages.

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

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

#14865

In article <mateh0$1np$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/4/2015 10:26 AM, Tim Streater wrote:
>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:

>>> Do your clients know you're generating invalid HTML for them?
>> 
>> My scripts don't generate HTML. They generate data, which is
>> interpreted client-side and used to update what is presented to the
>> user.
>
>So you use some convoluted method of sending data to a client and having
>something run on the client to interpret and display it?

Using ajax is hardly "convoluted". And the something is a browser. You
may have heard of them.

>Rather than simply generating HTML on the server and sending it to the
>client, like the rest of the world does?

I'm not generating web pages, I'm running an application. You know,
like where you double-click on an icon and an app starts and eventually
a window appears and the user does some stuff in it.

The PHP scripts (which also run on the user's machine) are a useful
backend where I can do stuff that browsers are not allowed to.

-- 
"A committee is a cul-de-sac down which ideas are lured and then 
 quietly strangled." - Sir Barnett Cocks (1907-1989)

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

#14869

On 2/4/2015 12:05 PM, Tim Streater wrote:
> In article <mateh0$1np$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>>> <jstucklex@attglobal.net> wrote:
> 
>>>> Do your clients know you're generating invalid HTML for them?
>>>
>>> My scripts don't generate HTML. They generate data, which is
>>> interpreted client-side and used to update what is presented to the
>>> user.
>>
>> So you use some convoluted method of sending data to a client and having
>> something run on the client to interpret and display it?
> 
> Using ajax is hardly "convoluted". And the something is a browser. You
> may have heard of them.
>

Yup, and overuse of ajax is very convoluted.

Besides - how do you get the ajax to the browser?  You said you didn't
generate any html.

>> Rather than simply generating HTML on the server and sending it to the
>> client, like the rest of the world does?
> 
> I'm not generating web pages, I'm running an application. You know,
> like where you double-click on an icon and an app starts and eventually
> a window appears and the user does some stuff in it.
> 
> The PHP scripts (which also run on the user's machine) are a useful
> backend where I can do stuff that browsers are not allowed to.
> 

This whole thread has been about web pages - until you popped in.

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

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

#14871

In article <matm2e$42c$2@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/4/2015 12:05 PM, Tim Streater wrote:
>> In article <mateh0$1np$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>>>> <jstucklex@attglobal.net> wrote:
>> 
>>>>> Do your clients know you're generating invalid HTML for them?
>>>>
>>>> My scripts don't generate HTML. They generate data, which is
>>>> interpreted client-side and used to update what is presented to the
>>>> user.
>>>
>>> So you use some convoluted method of sending data to a client and having
>>> something run on the client to interpret and display it?
>> 
>> Using ajax is hardly "convoluted". And the something is a browser. You
>> may have heard of them.
>>
>
>Yup, and overuse of ajax is very convoluted.
>
>Besides - how do you get the ajax to the browser?  You said you didn't
>generate any html.

The basic page is loaded when the app starts. It's an email client. So
it does what all email clients do - presents an interface in various
ways, downloads mail, filters it, checks for spam, saves into
databases. Presentation is done by the browser, all the rest by various
PHP scripts.

-- 
"The problem with defending the purity of the English language is that English
is about as pure as a cribhouse whore. We don't just borrow words; on occasion,
English has pursued other languages down alleyways to beat them unconscious 
and rifle their pockets for new vocabulary."            -- James Nicoll, rasfw

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

#14872

On 2/4/2015 1:14 PM, Tim Streater wrote:
> In article <matm2e$42c$2@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> On 2/4/2015 12:05 PM, Tim Streater wrote:
>>> In article <mateh0$1np$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 10:26 AM, Tim Streater wrote:
>>>>> In article <mat90n$af9$1@dont-email.me>, Jerry Stuckle
>>>>> <jstucklex@attglobal.net> wrote:
>>>>>
>>>>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>>>>> <jstucklex@attglobal.net> wrote:
>>>
>>>>>> Do your clients know you're generating invalid HTML for them?
>>>>>
>>>>> My scripts don't generate HTML. They generate data, which is
>>>>> interpreted client-side and used to update what is presented to the
>>>>> user.
>>>>
>>>> So you use some convoluted method of sending data to a client and
>>>> having
>>>> something run on the client to interpret and display it?
>>>
>>> Using ajax is hardly "convoluted". And the something is a browser. You
>>> may have heard of them.
>>>
>>
>> Yup, and overuse of ajax is very convoluted.
>>
>> Besides - how do you get the ajax to the browser?  You said you didn't
>> generate any html.
> 
> The basic page is loaded when the app starts. It's an email client. So
> it does what all email clients do - presents an interface in various
> ways, downloads mail, filters it, checks for spam, saves into
> databases. Presentation is done by the browser, all the rest by various
> PHP scripts.
> 

So you do generate HTML then.


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

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

#14873

Jerry Stuckle <jstucklex@attglobal.net> writes:

> On 2/4/2015 1:14 PM, Tim Streater wrote:
>> In article <matm2e$42c$2@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>> 
>> <snip>
>> 
>> The basic page is loaded when the app starts. It's an email client. So
>> it does what all email clients do - presents an interface in various
>> ways, downloads mail, filters it, checks for spam, saves into
>> databases. Presentation is done by the browser, all the rest by various
>> PHP scripts.
>> 
>
> So you do generate HTML then.

AJAX responses aren't typically HTML - why would you send HTML instead
of JSON?

Or are you inferring that JSON is HTML?

I *very* rarely see HTML as a result of an AJAX request, normally I see
JSON or plain text, which is then parsed via javascript and HTML
elements updated as necessary via DOM updates on the client side.

The text/html content type header is not even necessary in these cases.

I think more and more websites/SAAS are using and will be using AJAX
going forward - HTML is just a small part of a bigger picture. 

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

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

#14874

Matthew Carter wrote:

> I *very* rarely see HTML as a result of an AJAX request, normally I see
> JSON or plain text, which is then parsed via javascript and HTML
> elements updated as necessary via DOM updates on the client side.

Ajax stands for "Asynchronous JavaScript And XML".  So neither HTML,
JSON, nor plain text responses have anything to do with it -- otherwise,
where would be the XML? ;)

-- 
Christoph M. Becker

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

#14876

On 2/4/2015 3:54 PM, Christoph M. Becker wrote:
> Matthew Carter wrote:
> 
>> I *very* rarely see HTML as a result of an AJAX request, normally I see
>> JSON or plain text, which is then parsed via javascript and HTML
>> elements updated as necessary via DOM updates on the client side.
> 
> Ajax stands for "Asynchronous JavaScript And XML".  So neither HTML,
> JSON, nor plain text responses have anything to do with it -- otherwise,
> where would be the XML? ;)
> 

Yes, but the javascript needs to be sent to the browser in an HTML page.

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

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

#14875

On 2/4/2015 3:23 PM, Matthew Carter wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
> 
>> On 2/4/2015 1:14 PM, Tim Streater wrote:
>>> In article <matm2e$42c$2@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>> <snip>
>>>
>>> The basic page is loaded when the app starts. It's an email client. So
>>> it does what all email clients do - presents an interface in various
>>> ways, downloads mail, filters it, checks for spam, saves into
>>> databases. Presentation is done by the browser, all the rest by various
>>> PHP scripts.
>>>
>>
>> So you do generate HTML then.
> 
> AJAX responses aren't typically HTML - why would you send HTML instead
> of JSON?
> 
> Or are you inferring that JSON is HTML?
> 
> I *very* rarely see HTML as a result of an AJAX request, normally I see
> JSON or plain text, which is then parsed via javascript and HTML
> elements updated as necessary via DOM updates on the client side.
> 
> The text/html content type header is not even necessary in these cases.
> 
> I think more and more websites/SAAS are using and will be using AJAX
> going forward - HTML is just a small part of a bigger picture. 
> 

How do you get the AJAX to the browser if you don't generate HTML?


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

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

#14860

On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
> On 2/4/2015 8:29 AM, Tim Streater wrote:
>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>
>>>>> return does not create invalid output.  die() and exit() do.
>>>>>
>>>>> I have *never* found a need for either one in a properly constructed
>>>>> script.
>>
>>>> I use exit() after a header location combi.
>>>>
>>>> if (whatever){
>>>>      dostuff();
>>>>      header("location: ....");
>>>>      exit;
>>>> }
>>>>
>>>> It is an easy way to redirect, and terminate the script, and not having
>>>> a (possibly huge) else-part.
>>>>
>>>> Do you (Jerry) think that that approach isn't properly?
>>>> If so, why?
>>
>>> With a properly constructed script, you don't need to call exit() after
>>> a header() call, either.
>>
>> I use exit when processing is complete. Sometimes that happens inside
>> an "if" or other construct.
>>
>> I certainly don't intend, ever, to use convoluted if/then/else just so
>> that processing always arrives at the last line of a script.
>>
>
> Which terminates processing immediately - and anything after that point
> (such as </BODY> and </HTML> tags is not sent to the browser.  This
> causes an invalid page to be generated.
>
> Do your clients know you're generating invalid HTML for them?
>

In my above example, the script did something useful in doStuff();
Then, redirects to another page with the header("location: ....").

I never intended to give the idea my example was outputting HTML to a 
browser (but should have said so to avoid confusion).

I often use PHP to processing some posting/do some task, and when 
finished, set  header/location to another page. (That will also avoid 
the dreaded back-button/formpost confirmation that confuses most 
non-webprogrammers = 99.9% of the world).

So using exit() seems completely valid to me.

For clarity's sake: I dislike half-finished HTML too, just like you, and 
when the script produces output, it *should* finish the document in a 
valid way. No discussion there.

You just triggered me by your statement that you never use exit(), when 
you program properly.
I use exit for the very reason Tim Steater gave: to avoid too much code 
into if-then-else constructs, for the sake of finishing at some point at 
the end.
IMHO it makes the script less readable.

Regards,
Erwin Moller

PS: If in your opinion only MVC is proper programming, than I can see 
why you never encounter exit() anymore.

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

#14862

On 2/4/2015 10:39 AM, Erwin Moller wrote:
> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>> <jstucklex@attglobal.net> wrote:
>>>
>>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>>
>>>>>> return does not create invalid output.  die() and exit() do.
>>>>>>
>>>>>> I have *never* found a need for either one in a properly constructed
>>>>>> script.
>>>
>>>>> I use exit() after a header location combi.
>>>>>
>>>>> if (whatever){
>>>>>      dostuff();
>>>>>      header("location: ....");
>>>>>      exit;
>>>>> }
>>>>>
>>>>> It is an easy way to redirect, and terminate the script, and not
>>>>> having
>>>>> a (possibly huge) else-part.
>>>>>
>>>>> Do you (Jerry) think that that approach isn't properly?
>>>>> If so, why?
>>>
>>>> With a properly constructed script, you don't need to call exit() after
>>>> a header() call, either.
>>>
>>> I use exit when processing is complete. Sometimes that happens inside
>>> an "if" or other construct.
>>>
>>> I certainly don't intend, ever, to use convoluted if/then/else just so
>>> that processing always arrives at the last line of a script.
>>>
>>
>> Which terminates processing immediately - and anything after that point
>> (such as </BODY> and </HTML> tags is not sent to the browser.  This
>> causes an invalid page to be generated.
>>
>> Do your clients know you're generating invalid HTML for them?
>>
> 
> In my above example, the script did something useful in doStuff();
> Then, redirects to another page with the header("location: ....").
> 
> I never intended to give the idea my example was outputting HTML to a
> browser (but should have said so to avoid confusion).
> 
> I often use PHP to processing some posting/do some task, and when
> finished, set  header/location to another page. (That will also avoid
> the dreaded back-button/formpost confirmation that confuses most
> non-webprogrammers = 99.9% of the world).
> 
> So using exit() seems completely valid to me.
> 
> For clarity's sake: I dislike half-finished HTML too, just like you, and
> when the script produces output, it *should* finish the document in a
> valid way. No discussion there.
> 
> You just triggered me by your statement that you never use exit(), when
> you program properly.
> I use exit for the very reason Tim Steater gave: to avoid too much code
> into if-then-else constructs, for the sake of finishing at some point at
> the end.
> IMHO it makes the script less readable.
> 
> Regards,
> Erwin Moller
> 
> PS: If in your opinion only MVC is proper programming, than I can see
> why you never encounter exit() anymore.
> 

I never do use exit().  There is no need for it, even in your example.
Proper code structure eliminates the problem.  Structured programming
does not make code less readable, if it's done properly.  And it does
make the code more maintainable.  You don't have to, for instance, try
to analyze a bunch of code to determine why your change did not take
effect - because you had already exited the code earlier.

I've just seen too many problems in other languages such as C/C++ caused
by people not wanting to structure their code properly with if-then-else
statements - and the problems it can cause.

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

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

#14866

On 2/4/2015 4:57 PM, Jerry Stuckle wrote:
> On 2/4/2015 10:39 AM, Erwin Moller wrote:
>> On 2/4/2015 3:06 PM, Jerry Stuckle wrote:
>>> On 2/4/2015 8:29 AM, Tim Streater wrote:
>>>> In article <mat59b$qn4$1@dont-email.me>, Jerry Stuckle
>>>> <jstucklex@attglobal.net> wrote:
>>>>
>>>>> On 2/4/2015 7:19 AM, Erwin Moller wrote:
>>>>>> On 12/19/2014 4:59 PM, Jerry Stuckle wrote:
>>>>
>>>>>>> return does not create invalid output.  die() and exit() do.
>>>>>>>
>>>>>>> I have *never* found a need for either one in a properly constructed
>>>>>>> script.
>>>>
>>>>>> I use exit() after a header location combi.
>>>>>>
>>>>>> if (whatever){
>>>>>>       dostuff();
>>>>>>       header("location: ....");
>>>>>>       exit;
>>>>>> }
>>>>>>
>>>>>> It is an easy way to redirect, and terminate the script, and not
>>>>>> having
>>>>>> a (possibly huge) else-part.
>>>>>>
>>>>>> Do you (Jerry) think that that approach isn't properly?
>>>>>> If so, why?
>>>>
>>>>> With a properly constructed script, you don't need to call exit() after
>>>>> a header() call, either.
>>>>
>>>> I use exit when processing is complete. Sometimes that happens inside
>>>> an "if" or other construct.
>>>>
>>>> I certainly don't intend, ever, to use convoluted if/then/else just so
>>>> that processing always arrives at the last line of a script.
>>>>
>>>
>>> Which terminates processing immediately - and anything after that point
>>> (such as </BODY> and </HTML> tags is not sent to the browser.  This
>>> causes an invalid page to be generated.
>>>
>>> Do your clients know you're generating invalid HTML for them?
>>>
>>
>> In my above example, the script did something useful in doStuff();
>> Then, redirects to another page with the header("location: ....").
>>
>> I never intended to give the idea my example was outputting HTML to a
>> browser (but should have said so to avoid confusion).
>>
>> I often use PHP to processing some posting/do some task, and when
>> finished, set  header/location to another page. (That will also avoid
>> the dreaded back-button/formpost confirmation that confuses most
>> non-webprogrammers = 99.9% of the world).
>>
>> So using exit() seems completely valid to me.
>>
>> For clarity's sake: I dislike half-finished HTML too, just like you, and
>> when the script produces output, it *should* finish the document in a
>> valid way. No discussion there.
>>
>> You just triggered me by your statement that you never use exit(), when
>> you program properly.
>> I use exit for the very reason Tim Steater gave: to avoid too much code
>> into if-then-else constructs, for the sake of finishing at some point at
>> the end.
>> IMHO it makes the script less readable.
>>
>> Regards,
>> Erwin Moller
>>
>> PS: If in your opinion only MVC is proper programming, than I can see
>> why you never encounter exit() anymore.
>>
>
> I never do use exit().  There is no need for it, even in your example.
> Proper code structure eliminates the problem.

There is no "problem" to eliminate.
We differ in opinion here: When exit() is used properly (=in a logical 
place), it is all very clear what is going on.

   Structured programming
> does not make code less readable, if it's done properly.  And it does
> make the code more maintainable.  You don't have to, for instance, try
> to analyze a bunch of code to determine why your change did not take
> effect - because you had already exited the code earlier.

That totally depends on the place where the exit() is used.
I often have a bunch of these to process different kinds of situations:

if (whatever){
     dostuff();
     header("location: ....");
     exit;
}

if (whatever2){
     dostuff2();
     header("location: ....");
     exit;
}

If you would read through that code, you would surely find the exits 
right away, I am sure.

But, of course, when the exit() is hidden somewhere horribly deep away, 
in a totally idiotic place, then yes, that would be a problem.

In my opinion that is matter of programming hygiene.


>
> I've just seen too many problems in other languages such as C/C++ caused
> by people not wanting to structure their code properly with if-then-else
> statements - and the problems it can cause.
>

Well, yes.
C/C++ is really a different beast.
I use PHP for a reason: ease of programming in a forgiving environment 
(type juggling, no memory allocation, strong array structure/functions, 
  etc).

It is, of course, possible to screw up royally in any language.

I think I heard that line first from you when I entered usenet, a 
hundred years ago. :-)

Regards,
Erwin Moller

-- 
"That which can be asserted without evidence, can be dismissed without 
evidence."
-- Christopher Hitchens

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web