| Embedding HTML Within a PHP Statement [message #175980] |
Mon, 14 November 2011 07:29  |
Call Me Tom
Messages: 9
Registered: August 2011
Karma: 0
|
Junior Member |
|
|
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?
2. Is it considered good programming, bad programming or personal
preference?
Thanks for some insight,
Tom
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175983 is a reply to message #175980] |
Mon, 14 November 2011 10:10  |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 8:29 AM, 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.
Have you never seen constructs like these before?
<table>
<tbody>
<?php
foreach ($someDBResult as $oneRow){
?>
<tr>
<td>
<?php echo $oneRow["firstName"]; ?>
</td>
<td>
<?php echo $oneRow["initials"]; ?>
</td>
</tr>
<?php
}
?>
</tbody>
</table>
I bet you have seen that before.
> Today I found the following code in a working program:
>
> <?php if (!empty($error_message)) { ?>
> <p class="error"><?php echo $error_message; ?></p>
> <?php } ?>
>
Perfectly legal PHP code.
> 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)
No, it is not that hard to figure out.
Think in levels of nesting.
But I bet it was hard to implement for the developers. ;-)
> but rather
> 1. Does this only work in special cases or does it work in all
> cases?
It always worked as expected for me.
> 2. Is it considered good programming, bad programming or personal
> preference?
I call it personal preference.
When you have LOADS of conditional statements and loops, it is clearly
the time to clean up the code a bit, but that goes for each piece of
code, in any language.
When you are inside complex conditional structures, and you do not want
to restructure the code, the opening and closing of PHP tags will add
extra confusion, and using echo instead might help a little to keeps
things understandable (for humans).
The way I see it, when comparing the 2 approaches:
Dropping in and out:
<?php if (!empty($error_message)) { ?>
<p class="error"><?php echo $error_message; ?></p>
<?php } ?>
Compare to using echo:
<?php
if (!empty($error_message)) {
echo "<p class=\"error\">".$error_message."</p>";
}
?>
The former has the advantage that you can use literal HTML.
No escaping needed like in echo "".
The good thing about using echo instead is that you have a lot less
<?php and ?> messing up your code, which clearly reduces the readability
of that code.
You I think it is your own preference.
Personally I let my choice depend on the situation.
When I work on a project where PHP code and lay-out are NOT separated,
and the design-people will modify my PHP files (mostly adding
style-details), I prefer to drop in and out of PHP, so they don't have
to worry about escaping.
When you are the only one using the code, do whatever YOU think is the
most clear way: Escaping versus tag-soup.
Of course, when you use some templating system, the problem with
designers messing with your code mostly vanishes and the choice becomes
totally your preference.
just my 2 cent.
Regards,
Erwin
>
> Thanks for some insight,
> Tom
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175984 is a reply to message #175980] |
Mon, 14 November 2011 10:39 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <mhg1c7p6qe5ng95rfiguu1b0tu18143m4a(at)4ax(dot)com>,
Call Me Tom <noemail(at)nowhere(dot)com> 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:
>
> <?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?
> 2. Is it considered good programming, bad programming or personal
> preference?
Perfectly valid. I used to use that approach, but I find it makes it too
hard to keep it clear what I am doing. I have separate PHP, html, and JS
files. I've given up on using php to directly build pages in that way.
What I do instead is to use ajax to collect some data from a php script
and then use JS to interpret that data and adjust the page as necessary.
E.g. you might imagine that the user makes a selection. Instead of
submitting the page and then presenting them with an error message, far
better IMO to have a <div> that is normally empty, use ajax to send the
user's request to a PHP script. The PHP script attempts to perform the
user's request and then returns a results message (based on
success/failure, for example), that you can present in the <div> using
JavaScript. Much cleaner and much better from the user's PoV.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175985 is a reply to message #175984] |
Mon, 14 November 2011 10:57 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 11:39 AM, Tim Streater wrote:
> In article <mhg1c7p6qe5ng95rfiguu1b0tu18143m4a(at)4ax(dot)com>,
> Call Me Tom <noemail(at)nowhere(dot)com> 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:
>>
>> <?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?
>> 2. Is it considered good programming, bad programming or personal
>> preference?
>
> Perfectly valid. I used to use that approach, but I find it makes it too
> hard to keep it clear what I am doing. I have separate PHP, html, and JS
> files. I've given up on using php to directly build pages in that way.
>
> What I do instead is to use ajax to collect some data from a php script
> and then use JS to interpret that data and adjust the page as necessary.
>
> E.g. you might imagine that the user makes a selection. Instead of
> submitting the page and then presenting them with an error message, far
> better IMO to have a <div> that is normally empty, use ajax to send the
> user's request to a PHP script. The PHP script attempts to perform the
> user's request and then returns a results message (based on
> success/failure, for example), that you can present in the <div> using
> JavaScript. Much cleaner and much better from the user's PoV.
>
Hi Tim,
I don't think that approach is very recommendable.
At least not as a general recipe.
A few drawbacks:
- Your full ajax approach results in multiple requests to the server
(where one request would suffice without AJAX.).
- It also demands the client to have Javascript enabled.
- Many searchengines and their associated crawlers don't execute
Javascript, so they will be blind for that fetched content.
- In many cases the back button will give unexpected results, and
bookmarking a page becomes a guessing game.
And there are more drawbacks.
I also fail to see why you claim "much cleaner for the user POV".
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175986 is a reply to message #175985] |
Mon, 14 November 2011 11:49 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Erwin Moller wrote:
> On 11/14/2011 11:39 AM, Tim Streater wrote:
>> In article <mhg1c7p6qe5ng95rfiguu1b0tu18143m4a(at)4ax(dot)com>,
>> Call Me Tom <noemail(at)nowhere(dot)com> 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:
>>>
>>> <?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?
>>> 2. Is it considered good programming, bad programming or personal
>>> preference?
>>
>> Perfectly valid. I used to use that approach, but I find it makes it too
>> hard to keep it clear what I am doing. I have separate PHP, html, and JS
>> files. I've given up on using php to directly build pages in that way.
>>
>> What I do instead is to use ajax to collect some data from a php script
>> and then use JS to interpret that data and adjust the page as necessary.
>>
>> E.g. you might imagine that the user makes a selection. Instead of
>> submitting the page and then presenting them with an error message, far
>> better IMO to have a <div> that is normally empty, use ajax to send the
>> user's request to a PHP script. The PHP script attempts to perform the
>> user's request and then returns a results message (based on
>> success/failure, for example), that you can present in the <div> using
>> JavaScript. Much cleaner and much better from the user's PoV.
>>
>
>
> Hi Tim,
>
> I don't think that approach is very recommendable.
> At least not as a general recipe.
>
> A few drawbacks:
> - Your full ajax approach results in multiple requests to the server
> (where one request would suffice without AJAX.).
> - It also demands the client to have Javascript enabled.
> - Many searchengines and their associated crawlers don't execute
> Javascript, so they will be blind for that fetched content.
> - In many cases the back button will give unexpected results, and
> bookmarking a page becomes a guessing game.
>
> And there are more drawbacks.
>
> I also fail to see why you claim "much cleaner for the user POV".
>
I have to agree.
I mix and match most horribly BUT my editor (geany) highlights that
witch is HTML and that which is PHP..
And careful use of textual tools makes it pretty obvious at the source
code level so I don't confuse myself.
The user? well he only sees the rendering of the output. Not his problem!
Its a lot easier to read
?>"hello world"<?
than
echo \"hello world\"
>
> Regards,
> Erwin Moller
>
>
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175987 is a reply to message #175985] |
Mon, 14 November 2011 12:30 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <4ec0f420$0$6915$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
Erwin Moller
<Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)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.
> - 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.
> - 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.
> - 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.
> 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. 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.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175989 is a reply to message #175980] |
Mon, 14 November 2011 12:39 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175990 is a reply to message #175980] |
Mon, 14 November 2011 12:54 |
Gregor Kofler
Messages: 69
Registered: September 2010
Karma: 0
|
Member |
|
|
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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175991 is a reply to message #175983] |
Mon, 14 November 2011 13:07 |
Balazs Nadasdi
Messages: 7
Registered: November 2011
Karma: 0
|
Junior Member |
|
|
On Monday, November 14, 2011 11:10:15 AM UTC+1, Erwin Moller wrote:
> Have you never seen constructs like these before?
> <table>
> <tbody>
> <?php
> foreach ($someDBResult as $oneRow){
> ?>
> <tr>
> <td>
> <?php echo $oneRow["firstName"]; ?>
> </td>
> <td>
> <?php echo $oneRow["initials"]; ?>
> </td>
> </tr>
> <?php
> }
> ?>
> </tbody>
> </table>
more readable (i don't like this: <?php } ?>):
<table>
<tbody>
<?php foreach ($someDBResult as $oneRow): ?>
<tr>
<td>
<?=$oneRow["firstName"]; ?>
</td>
<td>
<?=$oneRow["initials"]; ?>
</td>
</tr>
<?php endforeach; ?>
</tbody>
</table>
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175992 is a reply to message #175991] |
Mon, 14 November 2011 13:19 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 8:07 AM, Balazs Nadasdi wrote:
> <?php foreach ($someDBResult as $oneRow): ?>
> <tr>
> <td>
> <?=$oneRow["firstName"]; ?>
> </td>
> <td>
> <?=$oneRow["initials"]; ?>
> </td>
> </tr>
> <?php endforeach; ?>
Other than the fact most hosts now have short_tags disabled, this will
work. But it's definitely not recognized by most php programmers, and
used by even fewer. IMHO it's better to stick along with commonly
accepted practices.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175993 is a reply to message #175991] |
Mon, 14 November 2011 13:29 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 2:07 PM, Balazs Nadasdi wrote:
> On Monday, November 14, 2011 11:10:15 AM UTC+1, Erwin Moller wrote:
>> Have you never seen constructs like these before?
>> <table>
>> <tbody>
>> <?php
>> foreach ($someDBResult as $oneRow){
>> ?>
>> <tr>
>> <td>
>> <?php echo $oneRow["firstName"]; ?>
>> </td>
>> <td>
>> <?php echo $oneRow["initials"]; ?>
>> </td>
>> </tr>
>> <?php
>> }
>> ?>
>> </tbody>
>> </table>
>
> more readable (i don't like this:<?php } ?>):
>
> <table>
> <tbody>
> <?php foreach ($someDBResult as $oneRow): ?>
> <tr>
> <td>
> <?=$oneRow["firstName"]; ?>
> </td>
> <td>
> <?=$oneRow["initials"]; ?>
> </td>
> </tr>
> <?php endforeach; ?>
> </tbody>
> </table>
Hi,
I agree it is more readable, but it also expects to have short_open_tag
set to on (or 1), which isn't always the case.
Many shared server environments this is set to off (0).
Hence, if you want to improve portability of your code, avoid those
short tags.
(Sometimes this can be overcome by using a .htaccess and override, but
that isn't always allowed either. You know: the straight-jacket shared
server.)
Of course, if you own the server and have no plans at all to ever move
your code, you can enjoy the short_open_tag. :-)
For myself, I stopped using it because of the above reasons.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175995 is a reply to message #175980] |
Mon, 14 November 2011 13:54 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175996 is a reply to message #175987] |
Mon, 14 November 2011 14:01 |
Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 1:30 PM, Tim Streater wrote:
> In article <4ec0f420$0$6915$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
> Erwin Moller
> <Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)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
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175997 is a reply to message #175996] |
Mon, 14 November 2011 14:39 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <4ec11f55$0$6973$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
Erwin Moller
<Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)com> wrote:
> On 11/14/2011 1:30 PM, Tim Streater wrote:
>> 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
I think the user gets a faster response.
>> 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]
Sounds like in this case that *was* the "break" pedal as the car ended
up broken :-)
But I understand you meant "brake" pedal.
>>> 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).
In the case of my app, it is an email client. Seen by the user as a
traditional application. In this case client and server are the same
machine. So I use JS to present to the user, and ajax to communicate
with the PHP scripts that do the required things with SQLite
sending/receiving mails. So if, say, the user marks a mail as "read",
they don't want the screen refreshed, just an icon changed.
I started writing this as a hobby activity after retirement to see
whether or not it was possible. It's been fun to learn about a lot of
stuff, including how to write a spam filter.
>> 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.
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'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.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #175999 is a reply to message #175997] |
Mon, 14 November 2011 17:07 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Tim Streater)
> Erwin Moller wrote:
>
>> 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?
Yes.
> That looks slow/clumsy. What about if you want to
> go back?
That's the main reason for separate pages/steps - you can easily go back
(and forth) the usual way.
> Often the page writers provide their own Back button in these
> cases.
Which are ugly, unreliable and not userfriendly. The browser's own back
button is the second-most used thing on a website (after the normal
links). Users know how to use it. It's always a bad idea to break it.
But it's not only the normal user which might have a problem with a
'back'-button replacement - more advanced users often use a browser with
more advanced features, e.g. special hotkeys, mouse gestures etc. Some
of these might not work anymore as expected if the typical behaviour of
a website is broken.
For example on an AJAX-"powered" site I usually have to use the mouse
and the site-internal navigation buttons (if they work and if I can
easily find them) to go where I want, while on a "normal" site I can
also use other and easier ways (built into the browser), for example
going back one page just by pressing the two buttons of my laptop's
touchpad in right-left-order (or left-right to move forward) without
having to position the cursor over some button on the page. Much easier.
> For such a set of pages, one could ask:
>
> 1) What does "Back" mean? (i.e., using the browser's Back button)
Back one page. There are situations where it makes sense to just reload
a part of a page, but if the whole context changes, it's much better to
keep it seperated and use different pages/URLs.
> 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?
A shop is a bad example here, but there are also many sites out there
which consist of just one page/script and load all their content via
AJAX. Many of them have problems similar to old frame-based sites.
> If I were implementing such a set, I would bookmarking/back-button:
>
> 1) Make it in effect a single page
You can easily control it by setting different URL parameters. Still a
single script, but different URLs, so you can easily go back and forth
by using the browser nav.
> 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.
Yes. Easily done with separate URLs.
> Use my own back/forward buttons for this and ensure
> that no data is lost as user goes back and forth.
No. Replacements for basic browser functions are always less reliable
and often enough completely unnecessary.
> 3) Offer shortcuts to the user such as address lookup based on postcode
> and house name/number
Still possible with single pages. That's one thing where AJAX can make
sense and really improve the usability. Completely relying on AJAX does
not.
> 4) Browser-back button to take you to page previous to checkout - with
> the option to go forward still with no data lost.
The browser's back button should take you back to the previous page, not
make a whole jump across several steps. When I'm on the last step of the
checkout process, e.g. confirmation, pressing 'back' should take me to
the step before, usually the payment method. Pressing 'back' again takes
me back to the address or something like that. Then going forth from the
address page directly to the confirmation page wouldn't be a problem if
the data of each page is sent to the server and kept in a session. Easy
to implement and as reliable as possible.
> 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.
Not everything that's possible really does improve the service. AJAX has
its uses, like any other technology, but it can also create new problems
and affect a site's usability and accessibility if not used properly.
Micha
--
http://mfesser.de/blickwinkel
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176000 is a reply to message #175987] |
Mon, 14 November 2011 18:52 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 14 Nov 2011 12:30:17 +0000, Tim Streater wrote:
> In article <4ec0f420$0$6915$e4fe514c(at)news2(dot)news(dot)xs4all(dot)nl>,
> Erwin Moller
> <Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176001 is a reply to message #175998] |
Mon, 14 November 2011 18:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 9:41 AM, Balazs Nadasdi wrote:
> <?php foreach(): ?>
> <?php endforeach; ?>
>
> These aren't short_tags.
>
> my<?= is only a rote. the essence of my answer is the bracket-less usage. But yes, there is the point.
<?= is using short_open_tags, and will not work on hosts with it
disabled. That's what I was talking about.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176002 is a reply to message #175996] |
Mon, 14 November 2011 19:18 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)news2(dot)news(dot)xs4all(dot)nl>,
>> Erwin Moller
>> <Since_humans_read_this_I_am_spammed_too_much(at)spamyourself(dot)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(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176004 is a reply to message #175991] |
Mon, 14 November 2011 19:54 |
houghi
Messages: 45
Registered: September 2011
Karma: 0
|
Member |
|
|
Balazs Nadasdi wrote:
> more readable (i don't like this: <?php } ?>):
>
> <table>
> <tbody>
> <?php foreach ($someDBResult as $oneRow): ?>
> <tr>
> <td>
> <?=$oneRow["firstName"]; ?>
> </td>
> <td>
> <?=$oneRow["initials"]; ?>
> </td>
> </tr>
> <?php endforeach; ?>
> </tbody>
> </table>
I would use something like:
<?php
echo "<table><tbody>";
foreach ($someDBResult as $oneRow);
echo "<tr><td>".$oneRow["firstName"]."</td>
<td>".$oneRow["initials"]."</td>
</tr>";
endforeach;
echo "</tbody></table>";
?>
The reason I do it this way is that for me it is less confusing as it
looks more like 'standard' HTML and is _for me_ easier to read after
several months.
Is there an advantage or disadvantage of using echo instead of print?
houghi
--
> This is written under the influence of tv channel
> BBC Two (as there was nothing else on).
> I am now watching : Great British Food Revival
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176005 is a reply to message #176003] |
Mon, 14 November 2011 20:22 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 11/14/2011 2:41 PM, Balazs Nadasdi wrote:
> <table>
> <tbody>
> <?php foreach ($someDBResult as $oneRow): ?>
> <tr>
> <td>
> <?php echo $oneRow["firstName"]; ?>
> </td>
> <td>
> <?php echo $oneRow["initials"]; ?>
> </td>
> </tr>
> <?php endforeach; ?>
> </tbody>
> </table>
>
> Is it ok? ^_^
Yes, that is much preferable.
BTW - it's considered good form to copy the relevant portions of the
message you are replying to (as I did here). That way people don't have
to search to find out what you're replying to (which may or may not
exist on their server).
Not everyone uses google groups to access usenet - in fact I would
suspect the vast majority of regulars here (and in many newsgroups) use
a real newsreader. It's much better.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176007 is a reply to message #176005] |
Tue, 15 November 2011 01:44 |
Balazs Nadasdi
Messages: 7
Registered: November 2011
Karma: 0
|
Junior Member |
|
|
On Monday, November 14, 2011 9:22:38 PM UTC+1, Jerry Stuckle wrote:
> BTW - it's considered good form to copy the relevant portions of the
> message you are replying to (as I did here). That way people don't have
> to search to find out what you're replying to (which may or may not
> exist on their server).
>
> Not everyone uses google groups to access usenet - in fact I would
> suspect the vast majority of regulars here (and in many newsgroups) use
> a real newsreader. It's much better.
Thanks for telling me. I use often Unison but some days ago I changed temporarily to Google Groups and it doesn't quote the original message automatically.
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176008 is a reply to message #175980] |
Tue, 15 November 2011 02:15 |
bobmct
Messages: 16
Registered: September 2010
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176009 is a reply to message #176004] |
Tue, 15 November 2011 22:15 |
Ross McKay
Messages: 14
Registered: January 2011
Karma: 0
|
Junior Member |
|
|
On Mon, 14 Nov 2011 20:54:25 +0100, houghi wrote:
> I would use something like:
> <?php
> echo "<table><tbody>";
> foreach ($someDBResult as $oneRow);
> echo "<tr><td>".$oneRow["firstName"]."</td>
> <td>".$oneRow["initials"]."</td>
> </tr>";
> endforeach;
> echo "</tbody></table>";
> ?>
> [...]
Or you could even use HEREDOC (IMHO, it's purpose-made for the job):
<?php
echo "<table><tbody>";
foreach ($someDBResult as $oneRow) {
echo <<<HTML
<tr>
<td>{$oneRow["firstName"]}</td>
<td>{$oneRow["initials"]}</td>
</tr>
HTML;
}
echo "</tbody></table>";
?>
Of course, you might need to htmlspecialchars() those values, which you
can't do in a HEREDOC... unless you happen to have an object reference
with a method that calls htmlspecialchars():
<?php
class X {
function html($text) { return htmlspecialchars($text); }
}
$x = new X();
echo "<table><tbody>";
foreach ($someDBResult as $oneRow) {
echo <<<HTML
<tr>
<td>{$x->html($oneRow["firstName"])}</td>
<td>{$x->html($oneRow["initials"])}</td>
</tr>
HTML;
}
echo "</tbody></table>";
?>
Given that I mainly put my code inside classes, it's pretty easy to
provide that html() method for HEREDOCs to call as $this->html(...)
However, what the OP found is pretty common in templates where the focus
is on HTML, not PHP; the PHP is there to add functionality but the
template is really about the design, and often the people editing
templates are proficient in HTML and CSS but not PHP.
--
Ross McKay, Toronto, NSW Australia
"The lawn could stand another mowing; funny, I don't even care"
- Elvis Costello
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176010 is a reply to message #175997] |
Tue, 15 November 2011 22:55 |
Gregor Kofler
Messages: 69
Registered: September 2010
Karma: 0
|
Member |
|
|
Am 2011-11-14 15:39, Tim Streater meinte:
> In article <4ec11f55$0$6973$e4fe514c(at)news2(dot)news(dot)xs4all(dot)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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176011 is a reply to message #176010] |
Tue, 15 November 2011 23:02 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <j9uqlb$daj$1(at)dont-email(dot)me>,
Gregor Kofler <usenet(at)gregorkofler(dot)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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176012 is a reply to message #176011] |
Tue, 15 November 2011 23:06 |
Gregor Kofler
Messages: 69
Registered: September 2010
Karma: 0
|
Member |
|
|
Am 2011-11-16 00:02, Tim Streater meinte:
> In article <j9uqlb$daj$1(at)dont-email(dot)me>,
> Gregor Kofler <usenet(at)gregorkofler(dot)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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176013 is a reply to message #176012] |
Wed, 16 November 2011 10:10 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <j9ur9a$hcq$1(at)dont-email(dot)me>,
Gregor Kofler <usenet(at)gregorkofler(dot)com> wrote:
> Am 2011-11-16 00:02, Tim Streater meinte:
>> In article <j9uqlb$daj$1(at)dont-email(dot)me>,
>> Gregor Kofler <usenet(at)gregorkofler(dot)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
|
|
|
|
| Re: Embedding HTML Within a PHP Statement [message #176018 is a reply to message #176013] |
Wed, 16 November 2011 14:23 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]