Re: Attempt to de-mystify AJAX

"Glen B" <no$pamwebmaster@no$pamforallspec.com> wrote in message
news:4366a823$0$10550$b9f67a60@xxxxxxxxxxxxxxxxxxxx
..> The biggest difference between my experience and your experience is the
> fact that I have been building a public commerce web site, while you have
> been building a focused BUI application on an IE-specific platform. I
> really wish I could make everyone use a specific browser for our web site,
> but the paying public isn't so accomodating.

No and Maybe. The browser-specificity in our app is *not the primary
issue*, tho' I've complained about it ad nauseum here and elsewhere. We
estimate 3-4 man-months to desensitize our app to IE, a burden, but not too
much so. And of course I'm working on a BUI linking to a database, which is
what I'd assume many of the posters here were interested in. I'm not
qualified on general Web applications, but mostly I'm talking methodologies
here, which are application-independent.

>> 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?
>>
> As long as you have a "submit()" that contains an existing key stored in
> it, then there is no problem maintaining the state data reference.
> Hyperlink from any FlashCONNECT application to a static plain-text HTML
> page. Then hyperlink from the static page back to FC. Try to find your
> hidden form variable. :P

On my application I (the designer, that is) am in control, and I simply
don't allow hyperlinks that can overlay the page. I know that can be a major
problem. "Hyperlinks" always open a new browser window. In our world,
there's absolutely no problem with that. Does this issue go away then? Is
this is an issue with Flashconnect? Or else I still don't get it.

>>>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.
>
> Web development != BUI.
I am talking about Web-Development-as-a-front-end-for-a-Database-server, so
I'll stay with the simpler nomenclature.

"Keep-alives" are not typically used in web
> development since you can never assume that the browser, or connection for
> that matter, will always be available when the user is active. Heck, the
> client IP address could change while they are shopping! We're talking
> about apples and grapes here. I'm commenting on general web technology as
> one typically sees from an e-commerce center or a news web site.

Yes, you are making a statement about "typical" Web app design. No argument
there. But I am talking about a solution to the disconnection problem. It's
as equally valid in my world as it would be in the "typical" Web
application. Just because they choose not to use it or don't need it does
not mean it is inapplicable.

And I realize I am misusing the term "keep-alive". Maybe "I-am-alive signal"
What I meant is that the server, from its state tables, can easily determine
whether the connection is valid or not, not the other way around, because it
expects a repetitive signal from the browser. So the server simply cleans up
locks and any other detritus when the browser is not longer alive.

>>> 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 separate 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?
>
> Umm... cookies are raw HTTP headers, available via CGI environment
> variables, and have absolutely nothing to do with JS, PHP, or any other
> client or server 3rd party technology. I don't know what you are talking
> about! Trust me, I know the ins and outs of HTTP services. :P

Again, I probably don't know enough about the multitudinous ways you can
reference data. In my book, I'd use :
var fields = unescape(document.cookie).split(...) or something, which, last
I looked, is javascript. What can you do on clientside with cookies that
does not involve javascript or another language (sincerely)?
>>
>>>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.
>
> True, but as I mentioned before - a non-dynamic request by the browser
> can easily ruin a browsing session by dropping the state data. I'm not
> saying one is better than the other, I'm merely stating the issues I've
> encountered when developing from all sides of the cube.

ibid (2).

>>> 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"?
>
> STATEFORM<A> in FRAME<A> goes to MYAPP
> USERFORM<A> in FRAME<B> goes to MYAPP
> FORM<B> in FRAME<B> goes to a newsletter subscription service
>
> *submit()*
> A, A, and B are all submitted at the same time from JS due to a DOM node
> reference discrepency between browser brand 1 and browser brand 2. Browser
> brand 1 is automatically sent to the scubscription page instead of back to
> the main application. Browser brand 2 works as expected. That is easily
> avoidable, but it _can_ happen for someone who isn't aware of the DOM and
> how to reference objects properly. You have a good grip on JS development,
> so you haven't encountered it. That's not to say that other, less
> knowledgeable, developers won't.

I guess I'd never encounter this since we always submit to the server, who
then decides what to do.

>>
>>> 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?
>
> Nevermind. We're talking apples and grapes again.
>
> "The session key should be maintained over hidden elements or
> URL-encoding" means exactly what it states. If you are using 'form posts'
> or 'URL gets' to maintain your state, then you have to maintain a session
> key(or session data) between submissions either by hidden fields for a
> POST submission or by specifying it via URL-encoding over a GET request.

On reading this carefully, it seems we are in *total agreement*-we need a
immutable session key?

Chandru Murthi

>>
>>>> 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
>
> Glen
>
>
>
> --
> Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
> ------->>>>>>http://www.NewsDemon.com<<<<<<------
> Unlimited Access, Anonymous Accounts, Uncensored Broadband Access


.

Relevant Pages

  • Re: How do we get there from here?
    ... In order to design using that ... > really focused on at this stage is browser enabled applications. ... This is a submission to the server, ... > Don't know much about cookies. ...
    (comp.databases.pick)
  • Re: Attempt to de-mystify AJAX
    ... >> poster said "I don't want to hodl tons of data in a hidden frame, ... I never use cookies so a user ... How do you "break" the session key? ... > as needed back to the server. ...
    (comp.databases.pick)
  • Re: Attempt to de-mystify AJAX
    ... >>maintaining a session via URL is not a problem. ... >> around cookies and JS, but it seems to be tough. ... >> as needed back to the server. ... but as I mentioned before - a non-dynamic request by the browser can ...
    (comp.databases.pick)
  • Re: My credit card details have been sent in the clear!
    ... The SSL protocol uses the "Servers" key to perform a handshake with the ... The net result is a session key (symetric key known by both the ... server and browser) that is then used to encrypt traffic going in both ...
    (comp.security.misc)
  • Re: Cookie mit Perl auslesen
    ... Und dann nimm Wireshark und gucke nach, ob dein Browser den Cookie auch ... Naja, Cookies werden durch entsprechende Anweisungen im HTTP-Header, den ... der Server zusammenbaut, durch den Klient gesetzt. ...
    (de.comp.lang.perl.misc)