Re: Attempt to de-mystify AJAX
- From: "Glen B" <no$pamwebmaster@no$pamforallspec.com>
- Date: Mon, 31 Oct 2005 18:26:22 -0500
> 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
>>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. "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.
>
>> 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?
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
>
>>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.
>
>> 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.
>
>> 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.
>
>>> 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
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.
Glen
--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDemon.com<<<<<<------
Unlimited Access, Anonymous Accounts, Uncensored Broadband Access
.
- Follow-Ups:
- Re: Attempt to de-mystify AJAX
- From: murthi
- Re: Attempt to de-mystify AJAX
- References:
- Re: Attempt to de-mystify AJAX
- From: Glen B
- Re: Attempt to de-mystify AJAX
- From: murthi
- Re: Attempt to de-mystify AJAX
- Prev by Date: Re: Attempt to de-mystify AJAX
- Next by Date: Re: Attempt to de-mystify AJAX
- Previous by thread: Re: Attempt to de-mystify AJAX
- Next by thread: Re: Attempt to de-mystify AJAX
- Index(es):
Relevant Pages
|
