Re: Attempt to de-mystify AJAX

embedded:
"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in message
news:4366740f$0$10494$b9f67a60@xxxxxxxxxxxxxxxxxxxxx
>
> "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
>>
>>> 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.
And in simplified English that means? How do you "break" the session key?
It's in an input element and gets transferred on a submit() just like any
other data. If it "breaks" there is no *meaningful* submit. Are you saying
it could "break" in a way that it mimics another session?

>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".
Of course, why is this a problem? You have a keep-alive signal as I
mentioned before.

> 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
Addressing your data structures has nothing to do with whether or not you
can maintain persistence. Personally I think it's a lot easier referencing
an element I set up as a hidden input field than segments of a cookie.
I don't do flaky scripting, or more correctly, scripting to get cookie parts
may be just as flaky as any other scripting. Has no relevance to the issues.
Also, how can you "work[ing] around cookies and JS" when you need JS to
access the cookie?

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

Seems like a good reason not to use cookies. Hidden Input fields never
expire.

> 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.
I don't see how you can do anything meaningful clientside if you have
reservations about referencing an element by name. What kind of applications
are you designing? If I had that restriction I could do absolutely nothing
at all.It's like saying that you want to write BASIC programs but you're not
allowed to have variables.Cross-browser Referencing issues are actually one
of the easier hurdles. What's a "submission mishap"?

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

Again, I'm lost. What is "integration framework"? What does "The session key
should be maintained over hidden elements or URL-encoding" mean?
It's hardly server overkill. client events are not typically server-enabled,
so you're talking about human data-entry speeds. The server call overhead is
measured in milliseconds on a typical 1-2 gHz server. What's the problem?

>> 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.
>>
See separate post.

In summary, I can say that I have been working with a IE-based BUI working
with a UV server for about 3 years. There are over 2 dozen site
installations, with thousands of interactions per day, with none of the
problems you describe. The types of problems we have are more
underlying-submit interruptions due to user clicking at random, for
instance; this required queuing the submits or disabling them sometimes
until the previous submit signaled completion; ensuring that the dreaded
pulldown didn't submit on every mouse-wheel turn (it generates an on-change
but there's ways around it); trying to get that same stupid pulldown to not
overlay everything in its path (this took several man-weeks) (ie, pulldowns
don't honor z-index) and many more. But none of them seem to have much to do
with your fears, unless I'm vastly misreading them. Please explain more
fully, I don't read jargon well.

Chandru Murthi
>
> 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


.