Re: Tabs and data

Discussion in 'HTML' started by Jerry Stuckle, Aug 5, 2009.

  1. sheldonlg wrote:
    > I've tried search this on Google, but obviously haven't come up with the
    > correct keywords. So, I am asking in these two groups for suggestions.
    >
    > I have a situation where I have to break up a number of fields over a
    > bunch of tabs. By tabs I don't mean the tabs in something like Firefox,
    > but more like the tabs you see when you set properties for an email
    > account. I know how to have the tabs come up, but they are really
    > independent pages. The problem is this:
    >
    > I would like to treat the totality of the data at one time for insertion
    > or updating of a record. However, when you move from tab to tab, all
    > data entered on the previous tab is lost. I thought about hidden
    > variables on the on all the tabs, but that would not work if you simply
    > go from one tab to another without a post button (on tab A to fill out
    > the corresponding hidden fields on tab B).
    >
    > So, other than inserting and updating one tab at a time piecemeal, how
    > does one go about it?


    Sheldon,

    This is the web, not an application. Browsers and HTML don't support tabs.

    BTW - why are you asking that here? PHP has nothing to do with what
    happens client-side. You should be asking in an HTML newsgroup.


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

    ==================
     
    Jerry Stuckle, Aug 5, 2009
    #1
    1. Advertising

  2. sheldonlg wrote:
    > Jerry Stuckle wrote:
    >> sheldonlg wrote:
    >>> I've tried search this on Google, but obviously haven't come up with
    >>> the correct keywords. So, I am asking in these two groups for
    >>> suggestions.
    >>>
    >>> I have a situation where I have to break up a number of fields over a
    >>> bunch of tabs. By tabs I don't mean the tabs in something like
    >>> Firefox, but more like the tabs you see when you set properties for
    >>> an email account. I know how to have the tabs come up, but they are
    >>> really independent pages. The problem is this:
    >>>
    >>> I would like to treat the totality of the data at one time for
    >>> insertion or updating of a record. However, when you move from tab
    >>> to tab, all data entered on the previous tab is lost. I thought
    >>> about hidden variables on the on all the tabs, but that would not
    >>> work if you simply go from one tab to another without a post button
    >>> (on tab A to fill out the corresponding hidden fields on tab B).
    >>>
    >>> So, other than inserting and updating one tab at a time piecemeal,
    >>> how does one go about it?

    >>
    >> Sheldon,
    >>
    >> This is the web, not an application. Browsers and HTML don't support
    >> tabs.
    >>
    >> BTW - why are you asking that here? PHP has nothing to do with what
    >> happens client-side. You should be asking in an HTML newsgroup.
    >>
    >>

    >
    > I asked here because I wanted to get the values off of all at once to
    > use for db insertion (as I explained in another reply). It didn't need
    > a php explanation as it turned out.
    >
    > Tabs are supported. They can be made with the <ul><li> format. As the
    > Captain suggested, they could be withing divs or spans that clicking on
    > the tabs either made visible or hidden. Thus they would all be on one
    > page so that the submit gets them all.
    >
    > I worked on that suggestion (with javascript) and got it to work
    > beautifully.
    >


    It makes no difference what you WANT to do. This isn't a PHP issue.

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

    ==================
     
    Jerry Stuckle, Aug 5, 2009
    #2
    1. Advertising

  3. sheldonlg wrote:
    > Jerry Stuckle wrote:
    >> sheldonlg wrote:
    >>> Jerry Stuckle wrote:
    >>>> sheldonlg wrote:
    >>>>> I've tried search this on Google, but obviously haven't come up
    >>>>> with the correct keywords. So, I am asking in these two groups for
    >>>>> suggestions.
    >>>>>
    >>>>> I have a situation where I have to break up a number of fields over
    >>>>> a bunch of tabs. By tabs I don't mean the tabs in something like
    >>>>> Firefox, but more like the tabs you see when you set properties for
    >>>>> an email account. I know how to have the tabs come up, but they
    >>>>> are really independent pages. The problem is this:
    >>>>>
    >>>>> I would like to treat the totality of the data at one time for
    >>>>> insertion or updating of a record. However, when you move from tab
    >>>>> to tab, all data entered on the previous tab is lost. I thought
    >>>>> about hidden variables on the on all the tabs, but that would not
    >>>>> work if you simply go from one tab to another without a post button
    >>>>> (on tab A to fill out the corresponding hidden fields on tab B).
    >>>>>
    >>>>> So, other than inserting and updating one tab at a time piecemeal,
    >>>>> how does one go about it?
    >>>>
    >>>> Sheldon,
    >>>>
    >>>> This is the web, not an application. Browsers and HTML don't
    >>>> support tabs.
    >>>>
    >>>> BTW - why are you asking that here? PHP has nothing to do with what
    >>>> happens client-side. You should be asking in an HTML newsgroup.
    >>>>
    >>>>
    >>>
    >>> I asked here because I wanted to get the values off of all at once to
    >>> use for db insertion (as I explained in another reply). It didn't
    >>> need a php explanation as it turned out.
    >>>
    >>> Tabs are supported. They can be made with the <ul><li> format. As
    >>> the Captain suggested, they could be withing divs or spans that
    >>> clicking on the tabs either made visible or hidden. Thus they would
    >>> all be on one page so that the submit gets them all.
    >>>
    >>> I worked on that suggestion (with javascript) and got it to work
    >>> beautifully.
    >>>

    >>
    >> It makes no difference what you WANT to do. This isn't a PHP issue.

    >
    > OK Jerry, please try to understand what I am going to say. It is the
    > same thing you have failed to understand before, both with me and with
    > many other posters.
    >
    > *YES*, as it turns out it is not a PHP issue. I, and others in the
    > past, have conceded that.
    >
    > AT THE TIME OF POSTING, it was not clear to me, nor to other posters in
    > the past in other threads, whether it was or was not a PHP issue. That
    > is why I, and other posters in the past on other threads, have included
    > both PHP and another group in the crossposting list.
    >


    It was clear to several people here that it was not a PHP issue.

    > If a thread continues, and it is clear it is not a PHP issue, I, and
    > others in the past on other threads, have removed it from the list of
    > crossposted newsgroups. I did that very thing with a reply to Lars
    > Eighner's post in this very thread. I didn't on this one because I
    > wanted YOU to see this response in the PHP newsgroup.
    >
    > What you seem to be asking is that OPs KNOW the ANSWER BEFORE they post.
    > That is, they should KNOW that the ANSWER does not lie in PHP, but in
    > something else. That, Jerry, is not practical. That is why people ask
    > questions in the various groups that SEEM TO apply (hopefully by
    > crossposting and not multiposting), to get maximum exposure to help
    > solve their problem.
    >
    > From past dealings, I know that you won't concede the point, but
    > hopefully you can at least take in under advisement.
    >


    Let's make it simple - even for you. You were talking how to do
    something on the browser. PHP doesn't run on the browser. It's not a
    PHP issue.

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

    ==================
     
    Jerry Stuckle, Aug 5, 2009
    #3
  4. sheldonlg wrote:
    > Jerry Stuckle wrote:
    >> sheldonlg wrote:
    >>> Jerry Stuckle wrote:
    >>>> sheldonlg wrote:
    >>>>> Jerry Stuckle wrote:
    >>>>>> sheldonlg wrote:
    >>>>>>> I've tried search this on Google, but obviously haven't come up
    >>>>>>> with the correct keywords. So, I am asking in these two groups
    >>>>>>> for suggestions.
    >>>>>>>
    >>>>>>> I have a situation where I have to break up a number of fields
    >>>>>>> over a bunch of tabs. By tabs I don't mean the tabs in something
    >>>>>>> like Firefox, but more like the tabs you see when you set
    >>>>>>> properties for an email account. I know how to have the tabs
    >>>>>>> come up, but they are really independent pages. The problem is
    >>>>>>> this:
    >>>>>>>
    >>>>>>> I would like to treat the totality of the data at one time for
    >>>>>>> insertion or updating of a record. However, when you move from
    >>>>>>> tab to tab, all data entered on the previous tab is lost. I
    >>>>>>> thought about hidden variables on the on all the tabs, but that
    >>>>>>> would not work if you simply go from one tab to another without a
    >>>>>>> post button (on tab A to fill out the corresponding hidden fields
    >>>>>>> on tab B).
    >>>>>>>
    >>>>>>> So, other than inserting and updating one tab at a time
    >>>>>>> piecemeal, how does one go about it?
    >>>>>>
    >>>>>> Sheldon,
    >>>>>>
    >>>>>> This is the web, not an application. Browsers and HTML don't
    >>>>>> support tabs.
    >>>>>>
    >>>>>> BTW - why are you asking that here? PHP has nothing to do with
    >>>>>> what happens client-side. You should be asking in an HTML newsgroup.
    >>>>>>
    >>>>>>
    >>>>>
    >>>>> I asked here because I wanted to get the values off of all at once
    >>>>> to use for db insertion (as I explained in another reply). It
    >>>>> didn't need a php explanation as it turned out.
    >>>>>
    >>>>> Tabs are supported. They can be made with the <ul><li> format.
    >>>>> As the Captain suggested, they could be withing divs or spans that
    >>>>> clicking on the tabs either made visible or hidden. Thus they
    >>>>> would all be on one page so that the submit gets them all.
    >>>>>
    >>>>> I worked on that suggestion (with javascript) and got it to work
    >>>>> beautifully.
    >>>>>
    >>>>
    >>>> It makes no difference what you WANT to do. This isn't a PHP issue.
    >>>
    >>> OK Jerry, please try to understand what I am going to say. It is the
    >>> same thing you have failed to understand before, both with me and
    >>> with many other posters.
    >>>
    >>> *YES*, as it turns out it is not a PHP issue. I, and others in the
    >>> past, have conceded that.
    >>>
    >>> AT THE TIME OF POSTING, it was not clear to me, nor to other posters
    >>> in the past in other threads, whether it was or was not a PHP issue.
    >>> That is why I, and other posters in the past on other threads, have
    >>> included both PHP and another group in the crossposting list.
    >>>

    >>
    >> It was clear to several people here that it was not a PHP issue.
    >>
    >>> If a thread continues, and it is clear it is not a PHP issue, I, and
    >>> others in the past on other threads, have removed it from the list of
    >>> crossposted newsgroups. I did that very thing with a reply to Lars
    >>> Eighner's post in this very thread. I didn't on this one because I
    >>> wanted YOU to see this response in the PHP newsgroup.
    >>>
    >>> What you seem to be asking is that OPs KNOW the ANSWER BEFORE they
    >>> post. That is, they should KNOW that the ANSWER does not lie in PHP,
    >>> but in something else. That, Jerry, is not practical. That is why
    >>> people ask questions in the various groups that SEEM TO apply
    >>> (hopefully by crossposting and not multiposting), to get maximum
    >>> exposure to help solve their problem.
    >>>
    >>> From past dealings, I know that you won't concede the point, but
    >>> hopefully you can at least take in under advisement.
    >>>

    >>
    >> Let's make it simple - even for you. You were talking how to do
    >> something on the browser. PHP doesn't run on the browser. It's not a
    >> PHP issue.
    >>

    >
    > Well, let's also keep it simple -- even for you! I was interested in
    > getting VALUES of fields -- in PHP -- from the browser. That means
    > $_POST. I needed it for several pages at once (or so I thought until
    > the visibility/hidden solution was presented to me). I didn't know even
    > IF that could be done in php. *THAT* was why I posted to PHP. I didn't
    > know AT THAT TIME that it could be solved EXCLUSIVELY on the browser.
    > *THAT* is the whole point that you seem to want to keep ignoring.
    >
    > Oh, and I also full well know that PHP runs on the server -- as I have
    > stated many times here on this newsgroup. Getting values FROM the
    > browser to use ON the server is the issue -- or are you denying there is
    > any communication between php and the browser.
    >
    > Get over it Jerry.
    >


    That is not what you asked, and not what people answered.

    Learn how to determine what is client side and what is server side.

    I'd suggest you get a job digging ditches, but then I would expect you
    couldn't figure out which end of the shovel to use, either.

    And no, there is no communication between PHP and the browser. All
    there is is HTML - PHP generates HTML and the browser responds with URI
    and/or header information. But there is NO COMMUNICATION BETWEEN PHP
    AND THE BROWSER.

    Get over it, Sheldon.

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

    ==================
     
    Jerry Stuckle, Aug 6, 2009
    #4
  5. Jerry Stuckle

    Curtis Dyer Guest

    On 05 Aug 2009, sheldonlg <sheldonlg> wrote:

    > Jerry Stuckle wrote:
    >> sheldonlg wrote:


    <snip>

    >> Sheldon,
    >>
    >> This is the web, not an application. Browsers and HTML don't
    >> support tabs.


    <snip>

    > Tabs are supported. They can be made with the <ul><li> format.


    Perhaps Jerry was referring to the actual widget avaialbe in GUI
    programming libs. However, I think I got the gist of what you
    meant.

    > As the Captain suggested, they could be withing divs or spans
    > that clicking on the tabs either made visible or hidden. Thus
    > they would all be on one page so that the submit gets them all.
    >
    > I worked on that suggestion (with javascript) and got it to work
    > beautifully.


    That sounds like the ideal solution, but what if client-side
    scripting is not enabled on the client?

    One possible workaround might involve using PHP's sessions, along
    with "next" and "previous" submit buttons, to navigate and retain
    settings from each "tab". It might be helpful to have the tabs do
    nothing by default (i.e., not clickable links). So, when scripting
    is not enabled, the tabs would just be a visual indication of
    users' progress in the overall process. Client-side scripting would
    simply make the "tabs" come to life when available.

    I realize the non-scripting approach isn't nearly as user-friendly,
    but it's better than nothing when scripting is disabled.

    --
    ~Curtis Dyer
    <? $x='<? $x=%c%s%c;printf($x,39,$x,39);?>';printf($x,39,$x,39);?>
     
    Curtis Dyer, Aug 6, 2009
    #5
  6. Jerry Stuckle

    Tim Streater Guest

    In article <h5dirm$q8m$-september.org>,
    Jerry Stuckle <> wrote:

    > sheldonlg wrote:


    [when will you clowns learn to snip]

    > > Well, let's also keep it simple -- even for you! I was interested in
    > > getting VALUES of fields -- in PHP -- from the browser. That means
    > > $_POST. I needed it for several pages at once (or so I thought until
    > > the visibility/hidden solution was presented to me). I didn't know even
    > > IF that could be done in php. *THAT* was why I posted to PHP. I didn't
    > > know AT THAT TIME that it could be solved EXCLUSIVELY on the browser.
    > > *THAT* is the whole point that you seem to want to keep ignoring.
    > >
    > > Oh, and I also full well know that PHP runs on the server -- as I have
    > > stated many times here on this newsgroup. Getting values FROM the
    > > browser to use ON the server is the issue -- or are you denying there is
    > > any communication between php and the browser.
    > >
    > > Get over it Jerry.
    > >

    >
    > That is not what you asked, and not what people answered.


    So he didn't know how to formulate the question properly first time
    round. Big fuckin' deal.

    > Learn how to determine what is client side and what is server side.
    >
    > I'd suggest you get a job digging ditches, but then I would expect you
    > couldn't figure out which end of the shovel to use, either.
    >
    > And no, there is no communication between PHP and the browser. All
    > there is is HTML - PHP generates HTML and the browser responds with URI
    > and/or header information. But there is NO COMMUNICATION BETWEEN PHP
    > AND THE BROWSER.


    You're such a pedant, Jerry. In my app I'm using ajax in the JavaScript
    to communicate with a load of PHP scripts. Sure, this goes via apache.
    But having set that up 8 months ago I've not had to think about the fact
    once in the interim. I just go on developing, and for all practical
    purposes can view it as communication between the browser and the PHP
    scripts.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Aug 6, 2009
    #6
  7. sheldonlg wrote:
    > Jerry Stuckle wrote:
    >> sheldonlg wrote:
    >>> Jerry Stuckle wrote:
    >>>> sheldonlg wrote:
    >>>>> Jerry Stuckle wrote:
    >>>>>> sheldonlg wrote:
    >>>>>>> Jerry Stuckle wrote:
    >>>>>>>> sheldonlg wrote:
    >>>>>>>>> I've tried search this on Google, but obviously haven't come up
    >>>>>>>>> with the correct keywords. So, I am asking in these two groups
    >>>>>>>>> for suggestions.
    >>>>>>>>>
    >>>>>>>>> I have a situation where I have to break up a number of fields
    >>>>>>>>> over a bunch of tabs. By tabs I don't mean the tabs in
    >>>>>>>>> something like Firefox, but more like the tabs you see when you
    >>>>>>>>> set properties for an email account. I know how to have the
    >>>>>>>>> tabs come up, but they are really independent pages. The
    >>>>>>>>> problem is this:
    >>>>>>>>>
    >>>>>>>>> I would like to treat the totality of the data at one time for
    >>>>>>>>> insertion or updating of a record. However, when you move from
    >>>>>>>>> tab to tab, all data entered on the previous tab is lost. I
    >>>>>>>>> thought about hidden variables on the on all the tabs, but that
    >>>>>>>>> would not work if you simply go from one tab to another without
    >>>>>>>>> a post button (on tab A to fill out the corresponding hidden
    >>>>>>>>> fields on tab B).
    >>>>>>>>>
    >>>>>>>>> So, other than inserting and updating one tab at a time
    >>>>>>>>> piecemeal, how does one go about it?
    >>>>>>>>
    >>>>>>>> Sheldon,
    >>>>>>>>
    >>>>>>>> This is the web, not an application. Browsers and HTML don't
    >>>>>>>> support tabs.
    >>>>>>>>
    >>>>>>>> BTW - why are you asking that here? PHP has nothing to do with
    >>>>>>>> what happens client-side. You should be asking in an HTML
    >>>>>>>> newsgroup.
    >>>>>>>>
    >>>>>>>>
    >>>>>>>
    >>>>>>> I asked here because I wanted to get the values off of all at
    >>>>>>> once to use for db insertion (as I explained in another reply).
    >>>>>>> It didn't need a php explanation as it turned out.
    >>>>>>>
    >>>>>>> Tabs are supported. They can be made with the <ul><li> format.
    >>>>>>> As the Captain suggested, they could be withing divs or spans
    >>>>>>> that clicking on the tabs either made visible or hidden. Thus
    >>>>>>> they would all be on one page so that the submit gets them all.
    >>>>>>>
    >>>>>>> I worked on that suggestion (with javascript) and got it to work
    >>>>>>> beautifully.
    >>>>>>>
    >>>>>>
    >>>>>> It makes no difference what you WANT to do. This isn't a PHP issue.
    >>>>>
    >>>>> OK Jerry, please try to understand what I am going to say. It is
    >>>>> the same thing you have failed to understand before, both with me
    >>>>> and with many other posters.
    >>>>>
    >>>>> *YES*, as it turns out it is not a PHP issue. I, and others in the
    >>>>> past, have conceded that.
    >>>>>
    >>>>> AT THE TIME OF POSTING, it was not clear to me, nor to other
    >>>>> posters in the past in other threads, whether it was or was not a
    >>>>> PHP issue. That is why I, and other posters in the past on other
    >>>>> threads, have included both PHP and another group in the
    >>>>> crossposting list.
    >>>>>
    >>>>
    >>>> It was clear to several people here that it was not a PHP issue.
    >>>>
    >>>>> If a thread continues, and it is clear it is not a PHP issue, I,
    >>>>> and others in the past on other threads, have removed it from the
    >>>>> list of crossposted newsgroups. I did that very thing with a reply
    >>>>> to Lars Eighner's post in this very thread. I didn't on this one
    >>>>> because I wanted YOU to see this response in the PHP newsgroup.
    >>>>>
    >>>>> What you seem to be asking is that OPs KNOW the ANSWER BEFORE they
    >>>>> post. That is, they should KNOW that the ANSWER does not lie in
    >>>>> PHP, but in something else. That, Jerry, is not practical. That
    >>>>> is why people ask questions in the various groups that SEEM TO
    >>>>> apply (hopefully by crossposting and not multiposting), to get
    >>>>> maximum exposure to help solve their problem.
    >>>>>
    >>>>> From past dealings, I know that you won't concede the point, but
    >>>>> hopefully you can at least take in under advisement.
    >>>>>
    >>>>
    >>>> Let's make it simple - even for you. You were talking how to do
    >>>> something on the browser. PHP doesn't run on the browser. It's not
    >>>> a PHP issue.
    >>>>
    >>>
    >>> Well, let's also keep it simple -- even for you! I was interested in
    >>> getting VALUES of fields -- in PHP -- from the browser. That means
    >>> $_POST. I needed it for several pages at once (or so I thought until
    >>> the visibility/hidden solution was presented to me). I didn't know
    >>> even IF that could be done in php. *THAT* was why I posted to PHP.
    >>> I didn't know AT THAT TIME that it could be solved EXCLUSIVELY on the
    >>> browser. *THAT* is the whole point that you seem to want to keep
    >>> ignoring.
    >>>
    >>> Oh, and I also full well know that PHP runs on the server -- as I
    >>> have stated many times here on this newsgroup. Getting values FROM
    >>> the browser to use ON the server is the issue -- or are you denying
    >>> there is any communication between php and the browser.
    >>>
    >>> Get over it Jerry.
    >>>

    >>
    >> That is not what you asked, and not what people answered.

    >
    > <sarcasm>
    > I guess I Jerry knows what I ask better than I do. He must be right.
    > After all, he is the Great Stuckle.
    >
    >>
    >> Learn how to determine what is client side and what is server side.
    >>
    >> I'd suggest you get a job digging ditches, but then I would expect you
    >> couldn't figure out which end of the shovel to use, either.

    >
    > You are such a wonderful person.
    >
    >>
    >> And no, there is no communication between PHP and the browser. All
    >> there is is HTML - PHP generates HTML and the browser responds with
    >> URI and/or header information. But there is NO COMMUNICATION BETWEEN
    >> PHP AND THE BROWSER.

    >
    > Wow! And all this time I thought that when I did a $_POST that the
    > information was coming from the html page submitted by the browser. How
    > could I have been so mistaken? After all, Jerry says there is no
    > communication between the php [on the server] and the browser. I wonder
    > where all those values actually come from?
    >
    > </sarcasm>
    >
    > This is my last response on this thread. I won't dirty myself any more
    > that was absolutely necessary. So, Jerry, you may sling away one last
    > time without a reprisal.
    >


    PHP generates HTML. Period. Whether this is handled by a browser or
    something else is completely immaterial. The HTTP request header
    contains data which may contain various items of data, some of which may
    end up as $_GET or $_POST variables. Whether it comes from a browser or
    something else is immaterial to PHP.

    Browsers do not run PHP code. When you ask about client side
    processing, you are NEVER talking about PHP. You've been told this time
    and time again. But I guess you're either too stupid to understand
    this, too lazy to try to find the appropriate newsgroup, or too full of
    yourself that you think this is your own personal newsgroup and we're
    all here just to answer the Great Sheldon's questions.

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

    ==================
     
    Jerry Stuckle, Aug 6, 2009
    #7
  8. Jerry Stuckle

    dorayme Guest

    In article <>,
    sheldonlg <sheldonlg> wrote:

    > I
    > meant, rather, that I wouldn't respond to Jerry again in this thread.


    This is obviously going to go on a while. How about everyone at least
    trimming everything down to the bare insults? Be completely honest,
    throw away the ball and just go on the field and slug it out, no need to
    stand on ceremony...

    --
    dorayme
     
    dorayme, Aug 6, 2009
    #8
  9. Jerry Stuckle

    Doug Miller Guest

    In article <h5eema$ov1$-september.org>, Jerry Stuckle <> wrote:

    >PHP generates HTML. Period.


    That's odd, I could've *sworn* I wrote a PHP script that retrieved data from a
    MySQL database.... <g>
     
    Doug Miller, Aug 6, 2009
    #9
  10. Doug Miller wrote:
    > In article <h5eema$ov1$-september.org>, Jerry Stuckle <> wrote:
    >
    >> PHP generates HTML. Period.

    >
    > That's odd, I could've *sworn* I wrote a PHP script that retrieved data from a
    > MySQL database.... <g>


    Don't be absurd. A MySQL database is not a web browser.

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

    ==================
     
    Jerry Stuckle, Aug 6, 2009
    #10
  11. Jerry Stuckle

    Andy Dingley Guest

    On 6 Aug, 09:20, Tim Streater <> wrote:

    > > And no, there is no communication between PHP and the browser.  All
    > > there is is HTML - PHP generates HTML and the browser responds with URI
    > > and/or header information.  But there is NO COMMUNICATION BETWEEN PHP
    > > AND THE BROWSER.

    >
    > You're such a pedant, Jerry.


    You think Jerry's a pedant, but he's nothing compared to an actual
    browser.

    Welcome to IT. Yes, the people are nit-picking, but you try asking a
    processor to "just do what I meant" instead. This stuff matters: it's
    the difference betwen hacking about with stuff until it doesn't look
    too bad, or actually understanding what's going on and groking it, so
    that you can focus on the application problem.

    Jerry's wording might not be particularly welcome to some reading
    this, but the fact is, he's spot-on for accuracy. It's a layered
    protocol: the hip bone is connected to the thigh bone etc., but there
    isn't any direct connection between PHP and the browser and so if you
    want things to work as if there was, you'd best find a way of encoding
    that communication into the HTTP & HTML channel between them, because
    that's all you have to work with.
     
    Andy Dingley, Aug 6, 2009
    #11
  12. Jerry Stuckle

    Tim Streater Guest

    In article
    <>,
    Andy Dingley <> wrote:

    > On 6 Aug, 09:20, Tim Streater <> wrote:
    >
    > > > And no, there is no communication between PHP and the browser.  All
    > > > there is is HTML - PHP generates HTML and the browser responds with URI
    > > > and/or header information.  But there is NO COMMUNICATION BETWEEN PHP
    > > > AND THE BROWSER.

    > >
    > > You're such a pedant, Jerry.

    >
    > You think Jerry's a pedant, but he's nothing compared to an actual
    > browser.
    >
    > Welcome to IT.


    Gosh, I've been waiting for that welcome for more than 40 years.

    > Yes, the people are nit-picking, but you try asking a
    > processor to "just do what I meant" instead. This stuff matters: it's
    > the difference betwen hacking about with stuff until it doesn't look
    > too bad, or actually understanding what's going on and groking it, so
    > that you can focus on the application problem.
    >
    > Jerry's wording might not be particularly welcome to some reading
    > this, but the fact is, he's spot-on for accuracy. It's a layered
    > protocol: the hip bone is connected to the thigh bone etc., but there
    > isn't any direct connection between PHP and the browser and so if you
    > want things to work as if there was, you'd best find a way of encoding
    > that communication into the HTTP & HTML channel between them, because
    > that's all you have to work with.


    Too bad you didn't read the rest of my post then, you know, the bit
    where I stated I'd sorted that channel out months ago, so now I just
    focus on the application problem.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Aug 6, 2009
    #12
  13. Andy Dingley wrote:
    > On 6 Aug, 09:20, Tim Streater <> wrote:
    >
    >>> And no, there is no communication between PHP and the browser. All
    >>> there is is HTML - PHP generates HTML and the browser responds with URI
    >>> and/or header information. But there is NO COMMUNICATION BETWEEN PHP
    >>> AND THE BROWSER.

    >> You're such a pedant, Jerry.

    >
    > You think Jerry's a pedant, but he's nothing compared to an actual
    > browser.
    >


    Too right. Browsers do something useful..

    And pedantically, there is communication between PHP and the browser.
    Done via the HTML protocol over TCP over PF over probably PPP over ATM o
    modem or ADSL protocol, probably over a mixture of media.
     
    The Natural Philosopher, Aug 6, 2009
    #13
  14. sheldonlg wrote:

    >
    > So, when I say "print" in php, which is on the server, I expect the
    > browser to print what I said to print in the php. We look at this as
    > *communication between the browser and the server*. Whether it gets
    > there by car, bus, train or plane is not usually important to us. We
    > only care that it gets there and quickly.


    Typical computer scientist..no clue about how the stuff actually works ;-)
     
    The Natural Philosopher, Aug 6, 2009
    #14
  15. Jerry Stuckle

    Doug Miller Guest

    In article <h5ev5r$fvi$-september.org>, Jerry Stuckle <> wrote:
    >Doug Miller wrote:
    >> In article <h5eema$ov1$-september.org>, Jerry Stuckle

    > <> wrote:
    >>
    >>> PHP generates HTML. Period.

    >>
    >> That's odd, I could've *sworn* I wrote a PHP script that retrieved data from a
    >> MySQL database.... <g>

    >
    >Don't be absurd. A MySQL database is not a web browser.
    >

    Having a humor-impaired day today, Jerry? :)
     
    Doug Miller, Aug 7, 2009
    #15
  16. sheldonlg wrote:
    > The Natural Philosopher wrote:
    >> sheldonlg wrote:
    >>
    >>>
    >>> So, when I say "print" in php, which is on the server, I expect the
    >>> browser to print what I said to print in the php. We look at this as
    >>> *communication between the browser and the server*. Whether it gets
    >>> there by car, bus, train or plane is not usually important to us. We
    >>> only care that it gets there and quickly.

    >>
    >> Typical computer scientist..no clue about how the stuff actually works
    >> ;-)

    >
    > I write programs that work. I couldn't care less about the circuity
    > that makes it all possible. All I think about is browser<==>server. I
    > leave the <==> to others to worry about.


    That's the difference between a coder and a programmer. The coder
    writes some lines and hopes they work. But when it doesn't work, the
    coder has no idea what's happening and has to go running for help (often
    to the wrong place).

    OTOH, the programmer understands the systems involved and their part in
    the whole process. While he won't be 100% accurate, the programmer can
    at least troubleshoot the problem to the failing area; in most cases he
    will find the problem and correct it.

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

    ==================
     
    Jerry Stuckle, Aug 7, 2009
    #16
  17. Jerry Stuckle

    dorayme Guest

    In article <>,
    sheldonlg <sheldonlg> wrote:

    > The Natural Philosopher wrote:
    > > sheldonlg wrote:
    > >
    > >>
    > >> So, when I say "print" in php, which is on the server, I expect the
    > >> browser to print what I said to print in the php. We look at this as
    > >> *communication between the browser and the server*. Whether it gets
    > >> there by car, bus, train or plane is not usually important to us. We
    > >> only care that it gets there and quickly.

    > >
    > > Typical computer scientist..no clue about how the stuff actually works ;-)

    >
    > I write programs that work. I couldn't care less about the circuity
    > that makes it all possible. All I think about is browser<==>server. I
    > leave the <==> to others to worry about.


    Me, I get into the copper wires and go up and down them, the fibre
    optics too. There is a whole world in there. Bit like the Paris Metro,
    see Luc Besson's movie, Subway

    --
    dorayme
     
    dorayme, Aug 7, 2009
    #17
  18. Jerry Stuckle

    Tim Streater Guest

    In article <h5fm25$suj$>,
    The Natural Philosopher <> wrote:

    > Andy Dingley wrote:
    > > On 6 Aug, 09:20, Tim Streater <> wrote:
    > >
    > >>> And no, there is no communication between PHP and the browser. All
    > >>> there is is HTML - PHP generates HTML and the browser responds with URI
    > >>> and/or header information. But there is NO COMMUNICATION BETWEEN PHP
    > >>> AND THE BROWSER.
    > >> You're such a pedant, Jerry.

    > >
    > > You think Jerry's a pedant, but he's nothing compared to an actual
    > > browser.
    > >

    >
    > Too right. Browsers do something useful..
    >
    > And pedantically, there is communication between PHP and the browser.
    > Done via the HTML protocol over TCP over PF over probably PPP over ATM o
    > modem or ADSL protocol, probably over a mixture of media.


    And having understood that, and coded my ajax wrapper, I cease to worry
    about it.

    And in my case, little of the above applies. The browser, apache, PHP,
    and SQLite are all on my own machine.

    --
    Tim

    "That excessive bail ought not to be required, nor excessive fines imposed,
    nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
     
    Tim Streater, Aug 7, 2009
    #18
  19. Jerry Stuckle

    John Hosking Guest

    F'up set to alt.html.
    No need to further annoy the PHP groupers with this drivel.

    On Fri, 07 Aug 2009 00:24:57 -0400, Ed Mullen wrote:

    > dorayme wrote:
    >>
    >> Me, I get into the copper wires and go up and down them, the fibre
    >> optics too. There is a whole world in there. Bit like the Paris Metro,
    >> see Luc Besson's movie, Subway
    >>


    When I'm doing testing and debugging, I feel more like another Besson
    character: <http://www.imdb.com/title/tt0110413/>

    Sometimes it goes very well for me; other times, not so much.

    >
    > I tried that for a while. The sparks kept igniting my ass. Or the
    > lasers kept frying my other private parts. Very freaking annoying.
    >
    > Still, I do love the technology. It's the people who keep f*****g it up.
    >
    > Damned annoying, those human participants!
    >
    > Hmm. Partici. Ok, I sorta get that, it connotes "partial." But the
    > rest? "pants?" Wuzzup wid dat?
    >
    > Participants? Hmm. People partially clad? Err. Partial people? People
    > with only one pants leg? Hmm.
    >
    > Ok, I really gotta get out more!


    Yes, good idea, Ed. Please get out!
    ;-)

    --
    John
    I remembered to add the smiley, right?
     
    John Hosking, Aug 7, 2009
    #19
  20. sheldonlg wrote:
    > The Natural Philosopher wrote:
    >> sheldonlg wrote:
    >>
    >>>
    >>> So, when I say "print" in php, which is on the server, I expect the
    >>> browser to print what I said to print in the php. We look at this as
    >>> *communication between the browser and the server*. Whether it gets
    >>> there by car, bus, train or plane is not usually important to us. We
    >>> only care that it gets there and quickly.

    >>
    >> Typical computer scientist..no clue about how the stuff actually works
    >> ;-)

    >
    > I write programs that work. I couldn't care less about the circuity
    > that makes it all possible. All I think about is browser<==>server. I
    > leave the <==> to others to worry about.


    You should. Or you might s[spend hours debugging code that didn't need it.

    I got a nice 4 week contract to 'sort out the bug' in some code I had
    written that had been adapted to run a new bit of hardware.

    Turned out the hardware was interacting with the onboard DMA controller
    during of all things, loading the code off a floppy disc. Remove
    hardware., load code, put hardware in. Happiness. Load code with
    hardware in place, two bytes of the code set to FFH. Odd..

    WE even managed to identify the sloppy hardware design and report it
    back to the vendors. Who simply shrugged and said 'it works for everyone
    else'

    Pah!
     
    The Natural Philosopher, Aug 7, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. qwweeeit
    Replies:
    2
    Views:
    680
    qwweeeit
    Dec 14, 2005
  2. Lars Eighner

    Re: Tabs and data

    Lars Eighner, Aug 5, 2009, in forum: HTML
    Replies:
    5
    Views:
    412
    dorayme
    Aug 6, 2009
  3. Captain Paralytic

    Re: Tabs and data

    Captain Paralytic, Aug 5, 2009, in forum: HTML
    Replies:
    1
    Views:
    410
    Captain Paralytic
    Aug 6, 2009
  4. rantingrick

    Tabs -vs- Spaces: Tabs should have won.

    rantingrick, Jul 16, 2011, in forum: Python
    Replies:
    95
    Views:
    1,928
    Roy Smith
    Jul 19, 2011
  5. John Kopanas
    Replies:
    2
    Views:
    321
    Gregory Brown
    Jan 29, 2007
Loading...

Share This Page