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

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

Embedding HTML Within a PHP Statement

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

Contents

  Embedding HTML Within a PHP Statement Call Me Tom <noemail@nowhere.com> - 2011-11-14 02:29 -0500
    Re: Embedding HTML Within a PHP Statement Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-14 11:10 +0100
      Re: Embedding HTML Within a PHP Statement Balazs Nadasdi <yitsushi@gmail.com> - 2011-11-14 05:07 -0800
        Re: Embedding HTML Within a PHP Statement Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-14 08:19 -0500
          Re: Embedding HTML Within a PHP Statement Balazs Nadasdi <yitsushi@gmail.com> - 2011-11-14 06:41 -0800
            Re: Embedding HTML Within a PHP Statement Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-14 13:59 -0500
              Re: Embedding HTML Within a PHP Statement Balazs Nadasdi <yitsushi@gmail.com> - 2011-11-14 11:41 -0800
                Re: Embedding HTML Within a PHP Statement Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-14 15:22 -0500
                  Re: Embedding HTML Within a PHP Statement Balazs Nadasdi <yitsushi@gmail.com> - 2011-11-14 17:44 -0800
        Re: Embedding HTML Within a PHP Statement Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-14 14:29 +0100
        Re: Embedding HTML Within a PHP Statement houghi <houghi@houghi.org.invalid> - 2011-11-14 20:54 +0100
          Re: Embedding HTML Within a PHP Statement Michael Fesser <netizen@gmx.de> - 2011-11-14 21:47 +0100
          Re: Embedding HTML Within a PHP Statement Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2011-11-16 09:15 +1100
    Re: Embedding HTML Within a PHP Statement Tim Streater <timstreater@greenbee.net> - 2011-11-14 10:39 +0000
      Re: Embedding HTML Within a PHP Statement Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-14 11:57 +0100
        Re: Embedding HTML Within a PHP Statement The Natural Philosopher <tnp@invalid.invalid> - 2011-11-14 11:49 +0000
        Re: Embedding HTML Within a PHP Statement Tim Streater <timstreater@greenbee.net> - 2011-11-14 12:30 +0000
          Re: Embedding HTML Within a PHP Statement Erwin Moller <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> - 2011-11-14 15:01 +0100
            Re: Embedding HTML Within a PHP Statement Tim Streater <timstreater@greenbee.net> - 2011-11-14 14:39 +0000
              Re: Embedding HTML Within a PHP Statement Michael Fesser <netizen@gmx.de> - 2011-11-14 18:07 +0100
              Re: Embedding HTML Within a PHP Statement Gregor Kofler <usenet@gregorkofler.com> - 2011-11-15 23:55 +0100
                Re: Embedding HTML Within a PHP Statement Tim Streater <timstreater@greenbee.net> - 2011-11-15 23:02 +0000
                  Re: Embedding HTML Within a PHP Statement Gregor Kofler <usenet@gregorkofler.com> - 2011-11-16 00:06 +0100
                    Re: Embedding HTML Within a PHP Statement Tim Streater <timstreater@greenbee.net> - 2011-11-16 10:10 +0000
                      Re: Embedding HTML Within a PHP Statement Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-16 14:23 +0000
            Re: Embedding HTML Within a PHP Statement Jerry Stuckle <jstucklex@attglobal.net> - 2011-11-14 14:18 -0500
          Re: Embedding HTML Within a PHP Statement Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 18:52 +0000
    Re: Embedding HTML Within a PHP Statement Arno Welzel <usenet@arnowelzel.de> - 2011-11-14 13:39 +0100
    Re: Embedding HTML Within a PHP Statement Gregor Kofler <usenet@gregorkofler.com> - 2011-11-14 13:54 +0100
    Re: Embedding HTML Within a PHP Statement Denis McMahon <denismfmcmahon@gmail.com> - 2011-11-14 13:54 +0000
    Re: Embedding HTML Within a PHP Statement bobm3@worthless.info - 2011-11-14 21:15 -0500

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

#3800

Am 2011-11-14 15:39, Tim Streater meinte:
> In article <4ec11f55$0$6973$e4fe514c@news2.news.xs4all.nl>,
> Erwin Moller

>> And what about bookmarking?
>> And intuitive use of the back button?
>>
>> Those things often feel broken to me when using AJAX-riddled websites.
> 
> Well, this is an interesting point. In the case of fairly static pages,
> bookmarking/back-button made sense. But if for example you are dealing
> with an on-line purchasing site, you "go to checkout" and then typically
> might go through a number of steps to complete the purchase. Should each
> of these be a separate page, so the page is entirely refreshed in order
> to go to the next one? That looks slow/clumsy. What about if you want to
> go back? Often the page writers provide their own Back button in these
> cases.
> 
> For such a set of pages, one could ask:
> 
> 1) What does "Back" mean? (i.e., using the browser's Back button)
> 2) Why should anyone bookmark a page in the middle of the set?
> 3) Why should a search engine note a page from the middle of the set?
> 
> If I were implementing such a set, I would bookmarking/back-button:
> 
> 1) Make it in effect a single page
> 2) Gather the sets of data (delivery address, credit-card data, etc) as
> different phases but allow the user to go back and forth to review each
> and/or correct any. Use my own back/forward buttons for this and ensure
> that no data is lost as user goes back and forth.
> 3) Offer shortcuts to the user such as address lookup based on postcode
> and house name/number
> 4) Browser-back button to take you to page previous to checkout - with
> the option to go forward still with no data lost.

I *hate* such "solutions" (there are some of those out there in the
wild). What happens when I click the real back button (or rather apply
the respective mouse gesture)? Right, I end up at the very beginning of
the purchase process and redo (or at least re-check) all my previous inputs.

> I'm sure most of us have used such checkout sites and have felt, as I
> have, that they offer variable quality in this department.
> 
> Anyway - that's nearly enough. I just feel that to offer a better
> service and make better use of the technology one ends up questioning
> bookmarking/back-button a little.

Questioning the back-button? Not even a little.

Gregor

-- 
http://vxweb.net

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

#3801

In article <j9uqlb$daj$1@dont-email.me>,
 Gregor Kofler <usenet@gregorkofler.com> wrote:

> Am 2011-11-14 15:39, Tim Streater meinte:

> > 4) Browser-back button to take you to page previous to checkout - with
> > the option to go forward still with no data lost.
> 
> I *hate* such "solutions" (there are some of those out there in the
> wild). What happens when I click the real back button (or rather apply
> the respective mouse gesture)? Right, I end up at the very beginning of
> the purchase process and redo (or at least re-check) all my previous inputs.

I don't trust any browser back button under those circumstances anyway. 
You click the browser back button a couple of times and expect all your 
data to still be there if you go forward again? I don't.

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

#3802

Am 2011-11-16 00:02, Tim Streater meinte:
> In article <j9uqlb$daj$1@dont-email.me>,
> Gregor Kofler <usenet@gregorkofler.com> wrote:
> 
>> Am 2011-11-14 15:39, Tim Streater meinte:
> 
>> > 4) Browser-back button to take you to page previous to checkout - with
>> > the option to go forward still with no data lost.
>>
>> I *hate* such "solutions" (there are some of those out there in the
>> wild). What happens when I click the real back button (or rather apply
>> the respective mouse gesture)? Right, I end up at the very beginning of
>> the purchase process and redo (or at least re-check) all my previous
>> inputs.
> 
> I don't trust any browser back button under those circumstances anyway.
> You click the browser back button a couple of times and expect all your
> data to still be there if you go forward again? I don't.
> 

That's not a problem of the browser back button, but of a sloppily
written web application.

Gregor

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

#3803

In article <j9ur9a$hcq$1@dont-email.me>,
 Gregor Kofler <usenet@gregorkofler.com> wrote:

> Am 2011-11-16 00:02, Tim Streater meinte:
> > In article <j9uqlb$daj$1@dont-email.me>,
> > Gregor Kofler <usenet@gregorkofler.com> wrote:
> > 
> >> Am 2011-11-14 15:39, Tim Streater meinte:
> > 
> >> > 4) Browser-back button to take you to page previous to checkout - with
> >> > the option to go forward still with no data lost.
> >>
> >> I *hate* such "solutions" (there are some of those out there in the
> >> wild). What happens when I click the real back button (or rather apply
> >> the respective mouse gesture)? Right, I end up at the very beginning of
> >> the purchase process and redo (or at least re-check) all my previous
> >> inputs.
> > 
> > I don't trust any browser back button under those circumstances anyway.
> > You click the browser back button a couple of times and expect all your
> > data to still be there if you go forward again? I don't.
> 
> That's not a problem of the browser back button, but of a sloppily
> written web application.

Indeed, strickly speaking. But I take the view that if someone has 
bothered to put their own navigation buttons in, there is a much greater 
likelihood that they'll have thought about my data and ensuring it's 
still there if i move back and forth a few times.

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

#3808

On Wed, 16 Nov 2011 10:10:14 +0000, Tim Streater wrote:

> ... I take the view that if someone has
> bothered to put their own navigation buttons in, there is a much greater
> likelihood that they'll have thought about my data and ensuring it's
> still there if i move back and forth a few times.

I like to think that too, doesn't always mean I'm right :(

Rgds

Denis McMahon

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

#3792

On 11/14/2011 9:01 AM, Erwin Moller wrote:
> On 11/14/2011 1:30 PM, Tim Streater wrote:
>> In article <4ec0f420$0$6915$e4fe514c@news2.news.xs4all.nl>,
>> Erwin Moller
>> <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> wrote:
>>
>>> I don't think that approach is very recommendable.
>>> At least not as a general recipe.
>
>
> Hello Tim,
>
>>
>> It won't cover many situations, I agree.
>>
>>> A few drawbacks:
>>> - Your full ajax approach results in multiple requests to the server
>>> (where one request would suffice without AJAX.).
>>
>> I would rather eat three correctly-sized meals a day than one very big
>> meal once a week.
>
> Me too.
> But your analogy doesn't explain why you think it is better.
>
> Are you stating that all-in-once versus multiple AJAX-calls is somehow
> better/easier for the server?
> Maybe lower memory-load of multiple small requests outperforms the
> higher memory load of one (bigger) request?
>
> But that is just guessing. I am curious what your rationale behind that
> statement is.
>
> Please don't respond with more food. :P
>
>
>>
>>> - It also demands the client to have Javascript enabled.
>>
>> Yes, and so what. My application has 7500 lines of PHP and 12000 or so
>> lines of javaScript. I see no prospect of being able to replace the
>> JavaScript by some clever CSS.
>
> I don't know your application of course.
> The reason I replied to your post is simply because in typical*
> situations it isn't necessarily a good approach.
>
> *By typical I mean: client/server, where:
> client=browser on some device,
> server=webserver serving HTML using PHP as language.
>
>
>>
>>> - Many searchengines and their associated crawlers don't execute
>>> Javascript, so they will be blind for that fetched content.
>>
>> While some might, and with good reason, personally I don't take the
>> needs of search engines into account.
>
> OK. Fair enough. :-)
>
>>
>>> - In many cases the back button will give unexpected results, and
>>> bookmarking a page becomes a guessing game.
>>
>> Mmm. In everything you say here, you make the mistake of assuming that
>> PHP, browser, JavaScript are components that can *only* be used in a
>> traditional browser-on-my-computer, server-somewhere-remote scenario.
>> This is an error.
>>
>
> Yes, I responded to the OP with that typical set-up in mind, since the
> OP didn't indicate anything else I saw little reason to do so.
>
> [short intermezzo at a driving school]
>
> Student: "So if I want to break I press the right pedal?"
> Driving instructor: "Correct."
>
> ...Student crashes into a wall trying to use right pedal to break...
>
> Student: "Why the $#$# did you tell me to use that right pedal?"
> Driving instructor: "Because that is where the breaks are in my 1891
> Daimler. It is a beautiful car by the way."
>
> [/short intermezzo]
>
> PS: I have no clue where the breaks actually are in a 1891 Daimler. ;-)
>
>
>>> I also fail to see why you claim "much cleaner for the user POV".
>>
>> Because reloading a page is messy and slow from the user's PoV. Instead
>> you can use AJAX to respond in a much more timely way depending what
>> they are doing. Or validate their form as they are entering it, or do
>> something like a postcode or address lookup.
>
> Yes, all the above are perfectly good examples where AJAX makes sense
> from a user POV. (I assume you validate the data again serverside.)
> I won't argue about that, and I use it myself in similar situations.
>
> But why build the better part of your document like that?
> Why fetch the main content via Ajax?
> I have seen this before, I understand how to do it, but I don't
> understand the why.
> The only valid reason I can think of is the flashing/buildup of the new
> document, but I never felt that out-weighted all the drawbacks (poor
> navigation/bookmarking are the worst).
>
>
>> And yes, in most instances
>> you can offer a degraded approach in the case where the user *has*
>> turned off JS, but then they get a poorer service and may not understand
>> why.
>
> And what about bookmarking?
> And intuitive use of the back button?
>
> Those things often feel broken to me when using AJAX-riddled websites.
>
> Regards,
> Erwin Moller
>
>

Erwin, you are correct.  Bringing everything down in one swell foop is 
much more efficient network-wise.

Assuming the data in both are identical, the same amount of data will be 
downloaded.  However, using AJAX requires multiple requests, along with 
the associated network traffic, server load and file system access than 
doing in one piece.  Additionally, if the server is using compression, 
it will almost assuredly be able to more efficiently compress one large 
block than several smaller blocks, further lowering both server load and 
network traffic.

Of course, that's not to mention the additional overhead on the client 
to interpret and process all that javascript (which, BTW, must also be 
downloaded - additional server and network traffic!).

AJAX has its uses - but using it in place of simply downloading the page 
is massive abuse, IMHO.

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

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

#3790

On Mon, 14 Nov 2011 12:30:17 +0000, Tim Streater wrote:

> In article <4ec0f420$0$6915$e4fe514c@news2.news.xs4all.nl>,
>  Erwin Moller
>  <Since_humans_read_this_I_am_spammed_too_much@spamyourself.com> wrote:
> 
>> I don't think that approach is very recommendable. At least not as a
>> general recipe.
> 
> It won't cover many situations, I agree.
> 
>> A few drawbacks:
>> - Your full ajax approach results in multiple requests to the server
>> (where one request would suffice without AJAX.).
> 
> I would rather eat three correctly-sized meals a day than one very big
> meal once a week.

Hmm

I tend to try and do all the processing, and then the output, usually 
with a heredoc for the latter.

Any dynamically generated content is tucked into variables during the 
processing section, so that all that happens during "output" is variable 
substitution in  the heredoc with {$phpVarName}.

I figure this is probably less resource intensive on the server than 
pausing during output to do processing.

I guess this is the "one big meal" approach, but I seem to think that it 
might mean that io resources are used more efficiently.

Rgds

Denis McMahon

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

#3779

Call Me Tom, 2011-11-14 08:29:

> I was under the impression that a section of PHP code (the part
> between <?PHP and ?>) was independent of any other section of PHP
> code.  Today I found the following code in a working program:
> 
>    <?php if (!empty($error_message)) { ?>
>    <p class="error"><?php echo $error_message; ?></p>
>    <?php } ?>
> 
> This is the first time I have seen a section of PHP code end in the
> middle of a PHP statement and restart after some HTML was inserted.  I
> was surpised that the PHP interpreter was able to connect the two
> sections of PHP code.

Well - this is the way how PHP works. The interpreter will just output
all the stuff between ?> and <?php without interpreting it.

> My question is not how the interpreter does it (that's way beyond my
> level of knowledge) but rather 
>   1. Does this only work in special cases or does it work in all
> cases?

This works in all cases. In fact this is by design, how PHP works.

>   2. Is it considered good programming, bad programming or personal
> preference?

It depends on the situation. Usually it's easier to embed large HTML
fragments than to output every single line using echo or print.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

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

#3780

Am 2011-11-14 08:29, Call Me Tom meinte:
> I was under the impression that a section of PHP code (the part
> between <?PHP and ?>) was independent of any other section of PHP
> code.  Today I found the following code in a working program:
> 
>    <?php if (!empty($error_message)) { ?>
>    <p class="error"><?php echo $error_message; ?></p>
>    <?php } ?>
> 
> This is the first time I have seen a section of PHP code end in the
> middle of a PHP statement and restart after some HTML was inserted.  I
> was surpised that the PHP interpreter was able to connect the two
> sections of PHP code.
> 
> My question is not how the interpreter does it (that's way beyond my
> level of knowledge) but rather 
>   1. Does this only work in special cases or does it work in all
> cases?

In all. After all PHP started out as a template engine.

>   2. Is it considered good programming, bad programming or personal
> preference?

Depends. I use above constructs frequently in my webpage templates (but
nowhere else).

Gregor

-- 
http://vxweb.net

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

#3785

On Mon, 14 Nov 2011 02:29:30 -0500, Call Me Tom wrote:

> I was under the impression that a section of PHP code (the part between
> <?PHP and ?>) was independent of any other section of PHP code.  Today I
> found the following code in a working program:

Nope. All the php code in a script shares the same environment.

eg in a single file:

-----------------------------------------
<?php
// some code
?>

some html

<?php
// some more code
?>

more html

<?php
// even more code
?>
-----------------------------------------

all the php code is operating with the same variables etc.

This means you can:

<?php
if (condition) {
?>

some html

<?php
}
?>

It might not be the tidiest way to do it (using heredoc is usually 
tidier), and I'm sure at least one purist will say "you shouldn't do it 
like that" but it works and it's valid php.

Rgds

Denis McMahon

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

#3798

FWIW - I have to read and maintain lots of php code written by others
all day long.  In my learned experience the drop in / drop out of php
again and again is a real pain on the eyes.

My preference is to output entire blocks of html code using heredocs
so the program actually never drops out of php.  

Something like this snippet:

<?php
. 
.
.
//*************************************************************************
// Default 'unknown' content
else {
	$_HeadWords = "Uh Oh!";
	$_Image = "pix/UhOh.jpg";
	$_Verbiage = "Content Indicator ($func) UNDEFINED!.";
}
//*************************************************************************
// Now print the column
 print <<<EOD
    <div id="left-column"><!-- Begin left-column area -->
   <img class="image-left" src="$_Image" height="189" width="299"
alt="$_Alt" />
<div style="margin: 10px 10px 10px 10px;"><!-- Begin inline style area
-->
<h3>$_HeadWords</h3>
<p class="align-left">$_Verbiage</p>
</div><!-- End inline style area -->
</div><!-- End left-column area -->
<div id="right-column"><!-- Begin of right-column area -->
EOD;
}
// End of _LeftColumn function
//******************************************************************************
.
.
.
?>

Preferences vary by individual.  But something like the above will
help the "next" guy who has to work with the code.

Bob

[toc] | [prev] | [standalone]

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

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

csiph-web