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

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

Nested PHP

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

Contents

  Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-10 20:24 +0000
    Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 15:56 -0500
      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-10 21:44 +0000
        Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 16:51 -0500
          Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-11 08:14 -0600
            Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 09:27 -0500
              Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-11 18:41 -0600
                Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 20:03 -0500
                  Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 10:13 +0000
                    Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-12 10:33 +0000
                    Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-12 06:30 -0500
                      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 12:52 +0000
                        Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-02-12 13:11 +0000
                        Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-13 06:55 +0000
                          Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-02-13 12:02 -0600
                    Re: Nested PHP Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2014-02-12 12:14 +0000
        Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-02-10 22:09 +0000
        Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-10 23:23 +0100
        Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-10 22:27 +0000
        Re: Nested PHP Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-02-11 09:30 +1100
        Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-10 23:06 +0000
          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-10 20:46 -0500
            Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 10:11 +0000
              Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-11 11:17 +0000
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 12:01 +0000
                  Re: Nested PHP Tim Streater <timstreater@greenbee.net> - 2014-02-11 12:45 +0000
                    Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-02-11 13:55 +0100
                      Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-11 13:29 +0000
                        Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 14:31 +0000
                          Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-11 17:24 +0000
              Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 08:15 -0500
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 14:31 +0000
                  Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 10:10 -0500
                    Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 15:31 +0000
                      Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 11:24 -0500
                        Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-12 10:13 +0000
                          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-12 06:33 -0500
                  Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 15:26 +0000
              Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 14:41 +0000
                Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-02-11 15:31 +0000
                  Re: Nested PHP Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-02-11 15:53 +0000
                  Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-02-11 11:26 -0500
        Re: Nested PHP bill <william@TechServSys.com> - 2014-02-11 07:12 -0500
    Re: Nested PHP richard <noreply@example.com> - 2014-02-12 09:33 -0500
      Re: Nested PHP Denis McMahon <denismfmcmahon@gmail.com> - 2014-02-13 06:47 +0000
        Re: Nested PHP Scott Johnson <noonehome@chalupasworld.com> - 2014-02-13 05:01 -0800
          Re: Nested PHP Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-02-14 07:19 -0800
            Re: Nested PHP Scott Johnson <noonehome@chalupasworld.com> - 2014-02-14 10:43 -0800
    Re: Nested PHP Arno Welzel <usenet@arnowelzel.de> - 2014-03-02 15:54 +0100
      Re: Nested PHP adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2014-03-02 18:10 +0000
      Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-03 11:38 +0000
        Re: Nested PHP Arno Welzel <usenet@arnowelzel.de> - 2014-03-17 15:26 +0100
          Re: Nested PHP Jerry Stuckle <jstucklex@attglobal.net> - 2014-03-17 10:52 -0400
          Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-17 15:33 +0000
            Re: Nested PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2014-03-17 17:10 -0500
              Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-17 23:01 +0000
                Re: Nested PHP Christoph Michael Becker <cmbecker69@arcor.de> - 2014-03-18 00:31 +0100
                  Re: Nested PHP The Natural Philosopher <tnp@invalid.invalid> - 2014-03-18 13:10 +0000
    Re: Nested PHP Gabe <usenet@moojuice.net> - 2014-03-17 15:18 +0000

Page 1 of 3  [1] 2 3  Next page →

#12759 — Nested PHP

I am using a php program to generate and download a webpage as an HTML
file, the HTML file draws its headers and navigation bar from another
HTML file using some embedded php with an "include" command.

The embedded php doesn't run when the file is downloaded, so the page
appears in the browser without its headers or navigation.

Is there a way of making the HTML file run the php or do I have to
tackle this from another angle?

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [next] | [standalone]

#12760

On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
> I am using a php program to generate and download a webpage as an HTML
> file, the HTML file draws its headers and navigation bar from another
> HTML file using some embedded php with an "include" command.
>
> The embedded php doesn't run when the file is downloaded, so the page
> appears in the browser without its headers or navigation.
>
> Is there a way of making the HTML file run the php or do I have to
> tackle this from another angle?
>

The PHP code in your generated file is only executed when the file is 
processed as a web page.  This is done by the web server, based on the 
file extension (default is .php; you do have that as the file extension, 
right?).

Any other means of downloading the file (i.e. ftp) will not cause the 
PHP code to be executed.

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

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

#12761

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
> > I am using a php program to generate and download a webpage as an HTML
> > file, the HTML file draws its headers and navigation bar from another
> > HTML file using some embedded php with an "include" command.
> >
> > The embedded php doesn't run when the file is downloaded, so the page
> > appears in the browser without its headers or navigation.
> >
> > Is there a way of making the HTML file run the php or do I have to
> > tackle this from another angle?
> >
> 
> The PHP code in your generated file is only executed when the file is
> processed as a web page.  This is done by the web server, based on the
> file extension (default is .php; you do have that as the file extension,
> right?).

Yes -  and the same code runs perfectly well with all its headers if the
file is sitting on the server and I call it up with a browser.  It is
only if I 'create' it on the fly from a php program that it doesn't work
- the HTML runs but the php doesn't.

> Any other means of downloading the file (i.e. ftp) will not cause the
> PHP code to be executed.

I was using a browser to view it, but the source code was coming from a
php program, not directly from a file on the server.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12762

On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
>>> I am using a php program to generate and download a webpage as an HTML
>>> file, the HTML file draws its headers and navigation bar from another
>>> HTML file using some embedded php with an "include" command.
>>>
>>> The embedded php doesn't run when the file is downloaded, so the page
>>> appears in the browser without its headers or navigation.
>>>
>>> Is there a way of making the HTML file run the php or do I have to
>>> tackle this from another angle?
>>>
>>
>> The PHP code in your generated file is only executed when the file is
>> processed as a web page.  This is done by the web server, based on the
>> file extension (default is .php; you do have that as the file extension,
>> right?).
>
> Yes -  and the same code runs perfectly well with all its headers if the
> file is sitting on the server and I call it up with a browser.  It is
> only if I 'create' it on the fly from a php program that it doesn't work
> - the HTML runs but the php doesn't.
>
>> Any other means of downloading the file (i.e. ftp) will not cause the
>> PHP code to be executed.
>
> I was using a browser to view it, but the source code was coming from a
> php program, not directly from a file on the server.
>
>

Anything output by a PHP program is sent directly to the client.  It is 
not processed (again) by the web server, so the php code you generate 
will never be processed.

The browser will see exactly what you sent - nothing more, nothing less.

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

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

#12785

On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
>> I was using a browser to view it, but the source code was coming from a
>> php program, not directly from a file on the server.
>>
>>
>
> Anything output by a PHP program is sent directly to the client.  It is 
> not processed (again) by the web server, so the php code you generate 
> will never be processed.
>
> The browser will see exactly what you sent - nothing more, nothing less.

Right.

Hmm... Might be worth trying writing to a temporary file, include()ing
it, then cleaning up at the end of the script. It's a LITTLE
complicated, but...

-- 
  For every rational explanation there are an infinite number of
  irrational explanations.
              -- Staples' Observation

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

#12786

On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
>>> I was using a browser to view it, but the source code was coming from a
>>> php program, not directly from a file on the server.
>>>
>>>
>>
>> Anything output by a PHP program is sent directly to the client.  It is
>> not processed (again) by the web server, so the php code you generate
>> will never be processed.
>>
>> The browser will see exactly what you sent - nothing more, nothing less.
>
> Right.
>
> Hmm... Might be worth trying writing to a temporary file, include()ing
> it, then cleaning up at the end of the script. It's a LITTLE
> complicated, but...
>

And subject to all kinds of problems - such as concurrency with others 
requesting the same page, getting rid of old copies, having to redirect 
the browser to the temporary file, the user bookmarking the temporary 
file... and probably several others.


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

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

#12799

On Tue, 11 Feb 2014 09:27:54 -0500, Jerry Stuckle wrote:
> On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
>> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
>>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
>>>> I was using a browser to view it, but the source code was coming from a
>>>> php program, not directly from a file on the server.
>>>>
>>>>
>>>
>>> Anything output by a PHP program is sent directly to the client.  It is
>>> not processed (again) by the web server, so the php code you generate
>>> will never be processed.
>>>
>>> The browser will see exactly what you sent - nothing more, nothing less.
>>
>> Right.
>>
>> Hmm... Might be worth trying writing to a temporary file, include()ing
>> it, then cleaning up at the end of the script. It's a LITTLE
>> complicated, but...
>>
>
> And subject to all kinds of problems - such as concurrency with others 
> requesting the same page, getting rid of old copies, having to redirect 
> the browser to the temporary file, the user bookmarking the temporary 
> file... and probably several others.

I think those are surmountable, with proper planning. Generating a
guaranteed unique filename for the temporary file is essentially a
solved problem, for example.

The big question, though, is why can't this be solved WITHOUT the clunky
mechanism. It almost smells richard-ish...

-- 
The trouble with things that extend your lifespan is that they happen 
at wrong end. I'd hate to be wearing Depends at 85 and thinking "I gave
up booze and cigarettes for three more years of this."

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

#12800

On 2/11/2014 7:41 PM, Peter H. Coffin wrote:
> On Tue, 11 Feb 2014 09:27:54 -0500, Jerry Stuckle wrote:
>> On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
>>> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
>>>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
>>>>> I was using a browser to view it, but the source code was coming from a
>>>>> php program, not directly from a file on the server.
>>>>>
>>>>>
>>>>
>>>> Anything output by a PHP program is sent directly to the client.  It is
>>>> not processed (again) by the web server, so the php code you generate
>>>> will never be processed.
>>>>
>>>> The browser will see exactly what you sent - nothing more, nothing less.
>>>
>>> Right.
>>>
>>> Hmm... Might be worth trying writing to a temporary file, include()ing
>>> it, then cleaning up at the end of the script. It's a LITTLE
>>> complicated, but...
>>>
>>
>> And subject to all kinds of problems - such as concurrency with others
>> requesting the same page, getting rid of old copies, having to redirect
>> the browser to the temporary file, the user bookmarking the temporary
>> file... and probably several others.
>
> I think those are surmountable, with proper planning. Generating a
> guaranteed unique filename for the temporary file is essentially a
> solved problem, for example.
>
> The big question, though, is why can't this be solved WITHOUT the clunky
> mechanism. It almost smells richard-ish...
>

That takes care of the concurrency problem - but that's all it takes 
care of.  When do you delete the file, for instance?  Or what if the 
user bookmarks the file?

But I also agree with you it sounds almost richard-ish.


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

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

#12803

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/11/2014 7:41 PM, Peter H. Coffin wrote:
> > On Tue, 11 Feb 2014 09:27:54 -0500, Jerry Stuckle wrote:
> >> On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
> >>> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
> >>>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
> >>>>> I was using a browser to view it, but the source code was coming from a
> >>>>> php program, not directly from a file on the server.
> >>>>>
> >>>>>
> >>>>
> >>>> Anything output by a PHP program is sent directly to the client.  It is
> >>>> not processed (again) by the web server, so the php code you generate
> >>>> will never be processed.
> >>>>
> >>>> The browser will see exactly what you sent - nothing more, nothing less.
> >>>
> >>> Right.
> >>>
> >>> Hmm... Might be worth trying writing to a temporary file, include()ing
> >>> it, then cleaning up at the end of the script. It's a LITTLE
> >>> complicated, but...
> >>>
> >>
> >> And subject to all kinds of problems - such as concurrency with others
> >> requesting the same page, getting rid of old copies, having to redirect
> >> the browser to the temporary file, the user bookmarking the temporary
> >> file... and probably several others.
> >
> > I think those are surmountable, with proper planning. Generating a
> > guaranteed unique filename for the temporary file is essentially a
> > solved problem, for example.
> >
> > The big question, though, is why can't this be solved WITHOUT the clunky
> > mechanism. It almost smells richard-ish...
> >
> 
> That takes care of the concurrency problem - but that's all it takes 
> care of.  When do you delete the file, for instance?  Or what if the 
> user bookmarks the file?

How do you delete the file?  I have tried a few 'obvious' (obvious to
me, that is) methods, but they don't seem to work.  I initially tried
going down the temporary file route, but my inability to find a way of
deleting the files was one reason why I abandoned it.


> But I also agree with you it sounds almost richard-ish.

Sorry if my beginner's questions sound like that, but I have started
trying to teach myself php from a position of almost complete ignorance,
especially in the way servers work.  My previous experience of using a
'server', if you can call it that, was programming in AlgolW under
Multics on an ICL System 4 mainframe in the 1970s; what little
programming I have done since then has been on desktop machines.

There are plenty of references to php on the Web, but using them to
learn a programming language is like trying to learn to drive a car by
reading detailed descriptions of the clutch pedal, the brake pedal and
the accelerator pedal.  

I feet I needed to read through a selection of easy-to-follow examples
of how real programmers solve real (straightforward) problems in the
world of php - but as these don't seem to be available in any sort of
collected form, I have turned to this group for guidance.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12805

In article <1lgy8o1.4vb3i3fbpwjqN%adrian@poppyrecords.invalid.invalid>,
Adrian Tuddenham <adrian@poppyrecords.invalid.invalid> wrote:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> > On 2/11/2014 7:41 PM, Peter H. Coffin wrote:
> > > On Tue, 11 Feb 2014 09:27:54 -0500, Jerry Stuckle wrote:
> > >> On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
> > >>> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
> > >>>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
> > >>>>> I was using a browser to view it, but the source code was coming from
> > >>>>> a
> > >>>>> php program, not directly from a file on the server.
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> Anything output by a PHP program is sent directly to the client.  It is
> > >>>> not processed (again) by the web server, so the php code you generate
> > >>>> will never be processed.
> > >>>>
> > >>>> The browser will see exactly what you sent - nothing more, nothing
> > >>>> less.
> > >>>
> > >>> Right.
> > >>>
> > >>> Hmm... Might be worth trying writing to a temporary file, include()ing
> > >>> it, then cleaning up at the end of the script. It's a LITTLE
> > >>> complicated, but...
> > >>>
> > >>
> > >> And subject to all kinds of problems - such as concurrency with others
> > >> requesting the same page, getting rid of old copies, having to redirect
> > >> the browser to the temporary file, the user bookmarking the temporary
> > >> file... and probably several others.
> > >
> > > I think those are surmountable, with proper planning. Generating a
> > > guaranteed unique filename for the temporary file is essentially a
> > > solved problem, for example.
> > >
> > > The big question, though, is why can't this be solved WITHOUT the clunky
> > > mechanism. It almost smells richard-ish...
> > >
> > 
> > That takes care of the concurrency problem - but that's all it takes 
> > care of.  When do you delete the file, for instance?  Or what if the 
> > user bookmarks the file?
> 
> How do you delete the file?  I have tried a few 'obvious' (obvious to
> me, that is) methods, but they don't seem to work.  I initially tried
> going down the temporary file route, but my inability to find a way of
> deleting the files was one reason why I abandoned it.

unlink ('/path/to/file');

> I felt I needed to read through a selection of easy-to-follow examples
> of how real programmers solve real (straightforward) problems in the
> world of php - but as these don't seem to be available in any sort of
> collected form, I have turned to this group for guidance.

Yes, in 2000 I was given a 20 minutes tutorial about PHP and webpages
by the chap doing the company's assets database; he then (having
resigned a little before) walked out the door and was not seen again.
Luckily for me I had 35 years of programming experience. That was my
intro to PHP, javascript, and how web servers work.

The best resource is the PHP web site; it's one reason I don't use
perl. PHP folks seem to do things in a straightforward way and don't
try to be smart-alecs.

See here for the docs:

<http://www.php.net/manual/en/>

You can find a simple example of how ajax can be used (how I use it in
my email client, f'rinstance) here:

<http://www.clothears.org.uk>

Anyway, keep coming back here with questions.

-- 
Tim

"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]

#12806

On 2/12/2014 5:13 AM, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/11/2014 7:41 PM, Peter H. Coffin wrote:
>>> On Tue, 11 Feb 2014 09:27:54 -0500, Jerry Stuckle wrote:
>>>> On 2/11/2014 9:14 AM, Peter H. Coffin wrote:
>>>>> On Mon, 10 Feb 2014 16:51:37 -0500, Jerry Stuckle wrote:
>>>>>> On 2/10/2014 4:44 PM, Adrian Tuddenham wrote:
>>>>>>> I was using a browser to view it, but the source code was coming from a
>>>>>>> php program, not directly from a file on the server.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Anything output by a PHP program is sent directly to the client.  It is
>>>>>> not processed (again) by the web server, so the php code you generate
>>>>>> will never be processed.
>>>>>>
>>>>>> The browser will see exactly what you sent - nothing more, nothing less.
>>>>>
>>>>> Right.
>>>>>
>>>>> Hmm... Might be worth trying writing to a temporary file, include()ing
>>>>> it, then cleaning up at the end of the script. It's a LITTLE
>>>>> complicated, but...
>>>>>
>>>>
>>>> And subject to all kinds of problems - such as concurrency with others
>>>> requesting the same page, getting rid of old copies, having to redirect
>>>> the browser to the temporary file, the user bookmarking the temporary
>>>> file... and probably several others.
>>>
>>> I think those are surmountable, with proper planning. Generating a
>>> guaranteed unique filename for the temporary file is essentially a
>>> solved problem, for example.
>>>
>>> The big question, though, is why can't this be solved WITHOUT the clunky
>>> mechanism. It almost smells richard-ish...
>>>
>>
>> That takes care of the concurrency problem - but that's all it takes
>> care of.  When do you delete the file, for instance?  Or what if the
>> user bookmarks the file?
>
> How do you delete the file?  I have tried a few 'obvious' (obvious to
> me, that is) methods, but they don't seem to work.  I initially tried
> going down the temporary file route, but my inability to find a way of
> deleting the files was one reason why I abandoned it.
>

Which is only one reason this is a bad way of doing it.  But these were 
questions to point out problems with this method.

BTW - to delete files, you use unlink().  See the documentation at 
www.php.net - it's the best reference around.

>
>> But I also agree with you it sounds almost richard-ish.
>
> Sorry if my beginner's questions sound like that, but I have started
> trying to teach myself php from a position of almost complete ignorance,
> especially in the way servers work.  My previous experience of using a
> 'server', if you can call it that, was programming in AlgolW under
> Multics on an ICL System 4 mainframe in the 1970s; what little
> programming I have done since then has been on desktop machines.
>
> There are plenty of references to php on the Web, but using them to
> learn a programming language is like trying to learn to drive a car by
> reading detailed descriptions of the clutch pedal, the brake pedal and
> the accelerator pedal.
>
> I feet I needed to read through a selection of easy-to-follow examples
> of how real programmers solve real (straightforward) problems in the
> world of php - but as these don't seem to be available in any sort of
> collected form, I have turned to this group for guidance.
>
>

Forget most of the web-based references.  There's a lot more crap out 
there than there is good stuff.  The best reference is the doc at 
www.php.net, as I said above.  Other than that, I would highly suggest 
you visit your local book store.  At least books have been through an 
editorial process, and in general are better.  Sorry I don't have any 
specific ones to suggest; it's been a while since I've looked.

Normally I also suggest your public library - but if it's like the one 
we have, the books will be several years old and way out of date for PHP.

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

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

#12810

Jerry Stuckle <jstucklex@attglobal.net> wrote:

> On 2/12/2014 5:13 AM, Adrian Tuddenham wrote:
> > Jerry Stuckle <jstucklex@attglobal.net> wrote:
> >
[...]
> > How do you delete the file?  I have tried a few 'obvious' (obvious to
> > me, that is) methods, but they don't seem to work.  I initially tried
> > going down the temporary file route, but my inability to find a way of
> > deleting the files was one reason why I abandoned it.
> >
> 
> Which is only one reason this is a bad way of doing it.  But these were
> questions to point out problems with this method.
> 
> BTW - to delete files, you use unlink().  See the documentation at 
> www.php.net - it's the best reference around.

I found that function and tried it, but the file didn't seem to go away
- its name was still visible even after I updated the file listings in
my ftp program.  Eventually I deleted it manually by ftp.

Perhaps I got something wrong or I didn't wait long enough before
checking; I'll try again.
> 
> >
> >> But I also agree with you it sounds almost richard-ish.
> >
> > Sorry if my beginner's questions sound like that, but I have started
> > trying to teach myself php from a position of almost complete ignorance,
> > especially in the way servers work.  My previous experience of using a
> > 'server', if you can call it that, was programming in AlgolW under
> > Multics on an ICL System 4 mainframe in the 1970s; what little
> > programming I have done since then has been on desktop machines.
> >
> > There are plenty of references to php on the Web, but using them to
> > learn a programming language is like trying to learn to drive a car by
> > reading detailed descriptions of the clutch pedal, the brake pedal and
> > the accelerator pedal.
> >
> > I feet I needed to read through a selection of easy-to-follow examples
> > of how real programmers solve real (straightforward) problems in the
> > world of php - but as these don't seem to be available in any sort of
> > collected form, I have turned to this group for guidance.
> >
> >
> 
> Forget most of the web-based references.  There's a lot more crap out
> there than there is good stuff.  The best reference is the doc at 
> www.php.net, as I said above.  Other than that, I would highly suggest
> you visit your local book store.  At least books have been through an
> editorial process, and in general are better.  Sorry I don't have any
> specific ones to suggest; it's been a while since I've looked.
> 
> Normally I also suggest your public library - but if it's like the one
> we have, the books will be several years old and way out of date for PHP.

I have put a visit to the bookshop on my shopping list for this
afternoon.  

[OT]
Sadly, not all books now go through a worthwhile editorial process.
There was a recent glaring example published by Focal Press of a book
relating to the history of analogue electronics (which is one of my
specialities) full of utter nonsense.  You couldn't really say the
statements contained 'errors', they were just complete gobbledeygook
made up by an author with no knowledge of the subject whatsoever.


-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

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

#12811

On 12/02/14 12:52, Adrian Tuddenham wrote:
>> BTW - to delete files, you use unlink().  See the documentation at
>> >www.php.net  - it's the best reference around.
> I found that function and tried it, but the file didn't seem to go away
> - its name was still visible even after I updated the file listings in
> my ftp program.  Eventually I deleted it manually by ftp.
>
> Perhaps I got something wrong or I didn't wait long enough before
> checking; I'll try again.

I found many issues when handling external files with PHP.

I conjectured that PHP caches files and filenames internally, only 
flushing to disk on exit.


For example writing a file to disk didn't happen so that mysql could use 
it in a load file command unless it was copy()ed first.

unlink() for a file generated within PHP did work. But the same is not 
true of files outside of it that may not have write permission for 
whatever process spawned PHP..

My response to these issues has been to insert binary data using a 
hexadecimal number string, instead of load file, and to use the mysql 
database as a repository for all data, rather than the native OS file 
system.

Mysql at least has a single unique interface and will queue asynchronous 
requests, so that it always does what it says on the tin.

AS far as access to PDFS go, the approach I would take is to put them in 
a database too in a BLOB, and use a php script to serve them that 
authenticates the user (as identified by a cookie)  as valid, or returns 
an unauthorised access code.

writing PHP for authorised users is not a noobs easiest task, but its is 
one that needs to be mastered if you are going to make the distinction 
between authorised and public access.,




-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

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

#12816

On Wed, 12 Feb 2014 12:52:49 +0000, Adrian Tuddenham wrote:

> You couldn't really say the
> statements contained 'errors', they were just complete gobbledeygook
> made up by an author with no knowledge of the subject whatsoever.

Yes, that would describe the majority of richard's code too. When he 
finally gets all the syntax errors sorted out, he's invariably left with 
a pile of syntactically correct gobbledeygook, which he then insists 
proves that php is broken because it doesn't actually do what he wants 
(invariably because he hasn't written code that does what he actually 
wants, he's written code that he thinks should do what he wants, and the 
two are about as close together as Voyager1 and Curiosity).

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#12821

On Thu, 13 Feb 2014 06:55:17 +0000 (UTC), Denis McMahon wrote:
> Yes, that would describe the majority of richard's code too. When he 
> finally gets all the syntax errors sorted out, he's invariably left with 
> a pile of syntactically correct gobbledeygook, which he then insists 
> proves that php is broken because it doesn't actually do what he wants 
> (invariably because he hasn't written code that does what he actually 
> wants, he's written code that he thinks should do what he wants, and the 
> two are about as close together as Voyager1 and Curiosity).

But it said "Space Probe" on the box! Why don't I feel it probing?

-- 
_  o
 |/)

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

#12809

On Wed, 12 Feb 2014 11:13:04 Adrian Tuddenham wrote:
> > >>> Might be worth trying writing to a temporary file, include()ing
> > >>> it, then cleaning up at the end of the script. It's a LITTLE
> > >>> complicated, but...

> > >> And subject to all kinds of problems - such as concurrency with
> > >> others requesting the same page, getting rid of old copies, having
> > >> to redirect the browser to the temporary file, the user bookmarking
> > >> the temporary file... and probably several others.

> How do you delete the file?  I have tried a few 'obvious' (obvious to
> me, that is) methods, but they don't seem to work.  I initially tried
> going down the temporary file route, but my inability to find a way of
> deleting the files was one reason why I abandoned it.

If you do something like:

-----------------------------------------
<?php

$file = tempnam('/tmp/', 'tmp');
$handle = fopen($file, 'w');
fwrite(
	$handle,
	'<html><body><p><?php echo "hello world"; ?></p></body></html>'
);
fclose($handle);

include $file;

unlink($file);

?>
-----------------------------------------

...then this is quite safe (one could create a race condition by
guessing the temporary filename and opening it in another process,
but this cannot be done from the outside and is thus IMHO rather
neglectible) and does what it should do.

But: 
 
> > > The big question, though, is why can't this be solved WITHOUT the
> > > clunky mechanism. It almost smells richard-ish...

That's the point. Even though the code above works, it is ugly and
very difficult to maintain. I would use it as a base for fun programs
and brainteasers ("read in the current program file, modify it, write
it out with a different name and include it" comes to my mind), but
definitely not for real world applications.

> Sorry if my beginner's questions sound like that, but I have started
> trying to teach myself php from a position of almost complete ignorance,
> especially in the way servers work.  My previous experience of using a
> 'server', if you can call it that, was programming in AlgolW under
> Multics on an ICL System 4 mainframe in the 1970s; what little
> programming I have done since then has been on desktop machines.

No problem with that. It's just that most things *can* be done in a much
easier way nowadays and therefore *should* be done that way.

Bye,
Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Die letzte Steigerungsform von "super", oder warum Stefan so massgebend eifert!
(Sloganizer)

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

#12763

On 10/02/14 21:44, Adrian Tuddenham wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>
>> On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
>>> I am using a php program to generate and download a webpage as an HTML
>>> file, the HTML file draws its headers and navigation bar from another
>>> HTML file using some embedded php with an "include" command.
>>>
>>> The embedded php doesn't run when the file is downloaded, so the page
>>> appears in the browser without its headers or navigation.
>>>
>>> Is there a way of making the HTML file run the php or do I have to
>>> tackle this from another angle?
>>>
>>
>> The PHP code in your generated file is only executed when the file is
>> processed as a web page.  This is done by the web server, based on the
>> file extension (default is .php; you do have that as the file extension,
>> right?).
>
> Yes -  and the same code runs perfectly well with all its headers if the
> file is sitting on the server and I call it up with a browser.  It is
> only if I 'create' it on the fly from a php program that it doesn't work
> - the HTML runs but the php doesn't.
>
>> Any other means of downloading the file (i.e. ftp) will not cause the
>> PHP code to be executed.
>
> I was using a browser to view it, but the source code was coming from a
> php program, not directly from a file on the server.
>
>
I haven't a clue what you are talking about which may be a strong hint 
that you havent a clue what you are doing...

Just provide an example of two files  that 'don't work'


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

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

#12764

Adrian Tuddenham wrote:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
>> On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
>>> I am using a php program to generate and download a webpage as an HTML
>>> file, the HTML file draws its headers and navigation bar from another
>>> HTML file using some embedded php with an "include" command.
>>>
>>> The embedded php doesn't run when the file is downloaded, so the page
>>> appears in the browser without its headers or navigation.
>>>
>>> Is there a way of making the HTML file run the php or do I have to
>>> tackle this from another angle?
>>>
>>
>> The PHP code in your generated file is only executed when the file is
>> processed as a web page.  This is done by the web server, based on the
>> file extension (default is .php; you do have that as the file extension,
>> right?).
> 
> Yes -  and the same code runs perfectly well with all its headers if the
> file is sitting on the server and I call it up with a browser.  It is
> only if I 'create' it on the fly from a php program that it doesn't work
> - the HTML runs but the php doesn't.

Why do you create PHP code on the fly?

-- 
Christoph M. Becker

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

#12765

In article <1lgvg1s.y70pl0agwbrgN%adrian@poppyrecords.invalid.invalid>,
Adrian Tuddenham <adrian@poppyrecords.invalid.invalid> wrote:

> Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> > On 2/10/2014 3:24 PM, Adrian Tuddenham wrote:
> > > I am using a php program to generate and download a webpage as an HTML
> > > file, the HTML file draws its headers and navigation bar from another
> > > HTML file using some embedded php with an "include" command.
> > >
> > > The embedded php doesn't run when the file is downloaded, so the page
> > > appears in the browser without its headers or navigation.
> > >
> > > Is there a way of making the HTML file run the php or do I have to
> > > tackle this from another angle?
> > 
> > The PHP code in your generated file is only executed when the file is
> > processed as a web page.  This is done by the web server, based on the
> > file extension (default is .php; you do have that as the file extension,
> > right?).
> 
> Yes -  and the same code runs perfectly well with all its headers if the
> file is sitting on the server and I call it up with a browser.  It is
> only if I 'create' it on the fly from a php program that it doesn't work
> - the HTML runs but the php doesn't.

Where is this PHP program that is doing this work "on the fly"? Where
is its input and what do you do with its output?
 
> > Any other means of downloading the file (i.e. ftp) will not cause the
> > PHP code to be executed.
> 
> I was using a browser to view it, but the source code was coming from a
> php program, not directly from a file on the server.

It's unclear to me what your sequence is. If you have the file locally
and open it from within the browser no PHP will be executed. It's the
remote webserver, if so configured, that hands off the requested file
to PHP which runs any PHP code within the file. The result of that is
then sent to your browser.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

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

#12766

adrian@poppyrecords.invalid.invalid says...

> I was using a browser to view it, but the source code was coming from 
> a php program, not directly from a file on the server.

What "php program"?  Do you mean just an engine-less editor?  If your 
"program" doesn't have an inbuilt PHP code parser then the include 
statements won't work.

GM

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web