Re: Attempt to de-mystify AJAX


"murthi" <c_xyz_murthi@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:qnt9f.10079$bD.1845@xxxxxxxxxxx
>
> "Tom deL" <ted@xxxxxxxxxxxxxx> wrote in message
> news:1130700529.639396.118430@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>>
>> <snip>
>>
>>> > Well yeah, it probably does, given the cost of round-tripping. More to
>>> > the point, the real advantage of Ajax is that it doesn't do a full
>>> > page
>>> > refresh, and I guess that's significant for some applications. But I
>>> > prefer to skirt around the issue by using frame sets.
>>>
>>> OK. That still works. I only watched from the side with the hidden
>>> frame approach and would prefer to not have to work with frames.
>>
>> Aside from everyone's attempts to say here that the old hidden/iframes
>> approaches are AJAX, I prefer the latter (lack of frames) for the same
>> reasons that I dislike javaScript: Frames work differently almost on a
>> per-seat basis. More complication in the programming that is due only
>> to stupid politics.
>
> May be getting too hung up on the hidden *frame* thing. Anothe thread
> poster said "I don't want to hodl tons of data in a hidden frame, I'd
> rather use cookies". Well, it's the same thing, ain' it? The client is
> holding both control and database data from the sever, and how and where
> it holds it is a matter of implementation. I never use cookies so a user
> turning off cokkies cannot destroy the application. I use about 2 doz.
> hidden *fields* with state information, and could possibly reduce that to
> one or two if I got sufficiently agitated.
>

What happens if someone goes outside of your POST/GET path? Everything is
dandy until a static file breaks the POST/GET cycle that maintains the
session key. If you are using HTTP as a 100% dynamic "user" environment then
maintaining a session via URL is not a problem. If; however, you are using
the web server to serve typical static and dynamic content then you are
going to run into "session drops". I know that from previous and current
experience. I am trying to working around cookies and JS, but it seems to be
tough. Hidden frames allow you to seperate the persistant and non-persistant
content, but send them both as needed back to the server. The problem that I
have with that is the fact that a frame has its own DOM and can not be
addressed as part of the overall document in focus. I don't like having
multiple document objects to deal with. Using cookies eliminates the need to
pass stuff back and forth manually, or through the use of potentially flakey
scripting. It's really a trade-off, depending on which way you look at it.
Everyone has an opinion of which is the best, but it really doesn't matter
how you do it. Here's the options I've solidified:

1) use cookies to maintain the session key and hope that the expiration tag
is recogized correctly. There has been expiration problems between IE and
Mozilla/Netscape for years and years. The hard to find problems seem to
float around and change after each new release of one or the other. Just
google for "cookie expiration problem". Each browser handles cookie values
and expiration values differently.

2) use javascript to post a hidden frame along with the rest of the parent
window's form, upon submission. This can lead to submission mishaps, though,
if you have multiple forms in the main frame. Naming and referencing can be
problematic between browsers. forms[index] and window.document.<formname>
are supposed to be identical but they both don't always work under every
browser. W3 consistency has gotten better over the years, but I still don't
trust calling stuff directly by element name. Each browser also has it's own
methods for obtaining node numbers by element names. It's really a PITA to
deal with.

3) Make every aspect of the website be derived from the dynamic engine. The
session key should be maintained over hidden elements or URL-encoding. This
means you have to run everything through MV. In a lot of cases, that's
server overkill. The intergration framework spends over 50% of the time
dumping static HTML. That is not a good thing if you are trying to
streamline your seat usage and/or cut costs.

> The point about state is that basically you need one handle that is passed
> back and forth like a baton. When client submits, server knows exactly
> what's happening by consulting its own state files for that handle.
>
>>> > Javascript can work fairly well, but if you're writing it by hand,
>>> > productivity is likely to be pretty low. Generated Javascript can do
>>> > the
>>> > job handily as well,
>
> No slower than writing BASIC or any other reasonably hi level language.
> Our web app has about 2000 lines of javascript, written over the last 3
> years. I don't consider that unmanageable at all. javascript is easy to
> write and has a decent debugger.
>

Er.. yeah.. decent debugger in what? FireFox? I.E.'s Jscript error notice
window blows chunks. I don't know how many "object" errors I've gotten for a
line, in which the line didn't even reference an object. The bug was
something completely different.

Glen



--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.

Quantcast