Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
cherrypy-users
+ new post
Home
About this group
Join this group
Message from discussion sessions/cookies
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
arjuna  
View profile  
 More options Sep 10 2008, 12:04 am
From: arjuna <brahmafor...@gmail.com>
Date: Wed, 10 Sep 2008 09:34:48 +0530
Local: Wed, Sep 10 2008 12:04 am
Subject: Re: [cherrypy-users] Re: sessions/cookies
Print | View thread | Show original | Report this message | Find messages by this author

>Adding AJAX to the mix ruins that.   Even if you are a programming
>wizard, and I immodestly count myself in that group, AJAX makes things
>freakin' complicated.  You are now deeply involved in client/server
>programming, with complicated inter-process communication.  (Yes,
>technically a CGI script is part of a client/server communication, but
>that's all hidden from me.)  State is split between the server and the
>client in ways that are not yet standardized and somewhat difficult to
>secure.

It seems that AJAX is necessary not from a technical perpective but a user
perspective. On web applications that have a lot of functionality and client
server communication page refreshes seem obsolete. My current app basically
has two pages a public page and a password protected page. The protected
page has many "contexts", ie instread of redirecting to another page, i use
the same page but use javascript and ajax to load different div tags to the
same page. So there is no redirect or refresh just different content loading
up.

I agree with you that maintaining state on the client and the server is a
pain, because both must be handled separately. I was doing this by passing
query parameters back and forth that include state information. This is not
straightforward, because of redirects to public pages if the user is not
logged in and other such issues...

However, yesterday I had the idea that a cookie seems like a good way to
synchronize state between client and server because it is accesible both by
python/cherrypy on the server side and javascript on the client side.

I am not currently using a javascript framework but am programming it
directly. I havent found any frameworks that seem to add value beyond their
own learning curve. Ie given my limited knowledge of js frameworks, it seems
that the frameworks add more complexity as their nuances have to be learned,
while the same effect can be achieved with a few lines of js code I checked
of Mochit and jquery they dont seem to have anything substantial to offer,
do correct me if i am wrong here.

On Wed, Sep 10, 2008 at 2:49 AM, Arnar Birgisson <arna...@gmail.com> wrote:

> Hi Gloria,

> On Tue, Sep 9, 2008 at 23:10, Gloria W <strang...@comcast.net> wrote:
> > Google is attempting to standardize on JSON transaction models, which is
> > interesting:
> > http://code.google.com/apis/protocolbuffers/
> > If proper AJAX support is added, this could be useful on the server
> > side. It may also turn out to be too bloated, ruining the elegance and
> > simplicity of JSON.

> ProtocolBuffers are not meant to replace JSON, they are just an
> efficient binary serialization format. The main thing that seperates
> ProtocolBuffers from other formats is version independence of
> messages, i.e. as long as you follow some simple rules for updating
> message descriptions, old messages remain valid on new descriptions
> and vice versa. Apart from that, PB can be likened to Adobe's AMF.

> If browser start supporting ProtocolBuffers natively and provide the
> interface for it to JS, they might very well become a good alternative
> to JSON, XML or ad-hoc text formats, but I think Google's intentions
> are different for now. HTTP performance is still the bottleneck so
> there is little to gain from more efficient data formats.

> cheers,
> Arnar

--
Best regards,
arjuna
http://www.brahmaforces.com

 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google