| 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:
|
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
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]