iCal to Drupal requires Content-Encoding: gzip
Locked
12
12
 
|
Hello,
We're trying to provide an iCal feed from Seaside (on VW) to Drupal. The Drupal use of the feed can be tested using a Google calendar iCal feed, and it works fine. We're able to produce a simple iCal document as well, but Drupal does not accept it. Both the Google and our Seaside iCal feeds download fine with just the browser. The one big difference we can see in the header is that the Google contains 'Content-Encoding: gzip' and ours does not. I have not be able to determine how we can properly provide the gzip compressed version of the content. Has anyone done an iCal feed from Seaside to Drupal? Or, how can I get the gzip properly to be properly supported in my data source? Thanks for any help, Bob Nemec Cherniak Software ---- Here are some details... Documentation on iCal in Drupal ... http://drupal.org/node/341716 http://www.drupalove.com/drupal-video/ical-events-nodes I'm packaging the response with... (aFilename=events.ics, aContent is a read stream on the string) WAResponse new contentType: 'text/calendar;charset=utf-8'; doNotCache; headerAt: 'Content-Disposition' put: 'attachment; filename="' , aFileName , '"'; headerAt: 'Content-length' put: aContents size printString; contents: aContents; yourself It looks like SeasideHttpWriteHandler>>prepareStream:forMessageBody: will do the compression with GZipWriteStream if useGZipTransfer = true, but I can't find a way to propagate that setting, and so far none of my attempts at hacking it are working. I had hoped something as simple as adding #headerAt: 'Content-Encoding' put: 'gzip' would work, but that just creates an invalid file. To see the header contents, we use the Live HTTP headers Firefox plug in. This is the Google header... http://www.google.com/calendar/ical/<our test calendar ics file> GET /calendar/ical/<our test calendar ics file> HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: <some cookie data> HTTP/1.x 200 OK Content-Type: text/calendar; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Mon, 21 Sep 2009 00:14:03 GMT Content-Encoding: gzip X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Content-Length: 3421 Server: GFE/2.0 ---------------------------------------------------------- And this is our Seaside header... http://localhost:48199/seaside/Test GET /seaside/Test HTTP/1.1 Host: localhost:48199 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:48199/seaside Cookie: <some cookie data> HTTP/1.x 200 OK Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-Control: no-cache,must-revalidate Pragma: no-cache Content-Disposition: attachment;filename=events.ics Content-Type: text/calendar;charset=utf-8 Content-Length: 10944 ---------------------------------------------------------- WAKomCompressed>>convertResponse: aResponse | response gzip stream | response := super convertResponse: aResponse. response fieldAt: 'Content-Encoding' put: 'gzip'. gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). gzip nextPutAll: aResponse contents contents; close. ^ response contents: stream reset _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
RE: iCal to Drupal requires Content-Encoding: gzip
|
|
Aren't you sending it as an attachment and google simply serving it in the contents? I see the following header in your response, but not in Google's? I agree with Philippe, it's very unlikely that gzipping is your problem.
Content-Disposition: attachment;filename=events.ics -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Monday, September 21, 2009 12:56 PM To: Seaside List Subject: [Seaside] iCal to Drupal requires Content-Encoding: gzip Hello, We're trying to provide an iCal feed from Seaside (on VW) to Drupal. The Drupal use of the feed can be tested using a Google calendar iCal feed, and it works fine. We're able to produce a simple iCal document as well, but Drupal does not accept it. Both the Google and our Seaside iCal feeds download fine with just the browser. The one big difference we can see in the header is that the Google contains 'Content-Encoding: gzip' and ours does not. I have not be able to determine how we can properly provide the gzip compressed version of the content. Has anyone done an iCal feed from Seaside to Drupal? Or, how can I get the gzip properly to be properly supported in my data source? Thanks for any help, Bob Nemec Cherniak Software ---- Here are some details... Documentation on iCal in Drupal ... http://drupal.org/node/341716 http://www.drupalove.com/drupal-video/ical-events-nodes I'm packaging the response with... (aFilename=events.ics, aContent is a read stream on the string) WAResponse new contentType: 'text/calendar;charset=utf-8'; doNotCache; headerAt: 'Content-Disposition' put: 'attachment; filename="' , aFileName , '"'; headerAt: 'Content-length' put: aContents size printString; contents: aContents; yourself It looks like SeasideHttpWriteHandler>>prepareStream:forMessageBody: will do the compression with GZipWriteStream if useGZipTransfer = true, but I can't find a way to propagate that setting, and so far none of my attempts at hacking it are working. I had hoped something as simple as adding #headerAt: 'Content-Encoding' put: 'gzip' would work, but that just creates an invalid file. To see the header contents, we use the Live HTTP headers Firefox plug in. This is the Google header... http://www.google.com/calendar/ical/<our test calendar ics file> GET /calendar/ical/<our test calendar ics file> HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: <some cookie data> HTTP/1.x 200 OK Content-Type: text/calendar; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Mon, 21 Sep 2009 00:14:03 GMT Content-Encoding: gzip X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Content-Length: 3421 Server: GFE/2.0 ---------------------------------------------------------- And this is our Seaside header... http://localhost:48199/seaside/Test GET /seaside/Test HTTP/1.1 Host: localhost:48199 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:48199/seaside Cookie: <some cookie data> HTTP/1.x 200 OK Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-Control: no-cache,must-revalidate Pragma: no-cache Content-Disposition: attachment;filename=events.ics Content-Type: text/calendar;charset=utf-8 Content-Length: 10944 ---------------------------------------------------------- WAKomCompressed>>convertResponse: aResponse | response gzip stream | response := super convertResponse: aResponse. response fieldAt: 'Content-Encoding' put: 'gzip'. gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). gzip nextPutAll: aResponse contents contents; close. ^ response contents: stream reset _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: iCal to Drupal requires Content-Encoding: gzip
|
|
By the way, it might be easier to compare text files obtained with curl,
curl -iL http://www.google.com > google.txt curl -iL http://www.microsoft.com > microsoft.txt -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov Sent: Monday, September 21, 2009 1:51 PM To: Seaside - general discussion Subject: RE: [Seaside] iCal to Drupal requires Content-Encoding: gzip Aren't you sending it as an attachment and google simply serving it in the contents? I see the following header in your response, but not in Google's? I agree with Philippe, it's very unlikely that gzipping is your problem. Content-Disposition: attachment;filename=events.ics -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: Monday, September 21, 2009 12:56 PM To: Seaside List Subject: [Seaside] iCal to Drupal requires Content-Encoding: gzip Hello, We're trying to provide an iCal feed from Seaside (on VW) to Drupal. The Drupal use of the feed can be tested using a Google calendar iCal feed, and it works fine. We're able to produce a simple iCal document as well, but Drupal does not accept it. Both the Google and our Seaside iCal feeds download fine with just the browser. The one big difference we can see in the header is that the Google contains 'Content-Encoding: gzip' and ours does not. I have not be able to determine how we can properly provide the gzip compressed version of the content. Has anyone done an iCal feed from Seaside to Drupal? Or, how can I get the gzip properly to be properly supported in my data source? Thanks for any help, Bob Nemec Cherniak Software ---- Here are some details... Documentation on iCal in Drupal ... http://drupal.org/node/341716 http://www.drupalove.com/drupal-video/ical-events-nodes I'm packaging the response with... (aFilename=events.ics, aContent is a read stream on the string) WAResponse new contentType: 'text/calendar;charset=utf-8'; doNotCache; headerAt: 'Content-Disposition' put: 'attachment; filename="' , aFileName , '"'; headerAt: 'Content-length' put: aContents size printString; contents: aContents; yourself It looks like SeasideHttpWriteHandler>>prepareStream:forMessageBody: will do the compression with GZipWriteStream if useGZipTransfer = true, but I can't find a way to propagate that setting, and so far none of my attempts at hacking it are working. I had hoped something as simple as adding #headerAt: 'Content-Encoding' put: 'gzip' would work, but that just creates an invalid file. To see the header contents, we use the Live HTTP headers Firefox plug in. This is the Google header... http://www.google.com/calendar/ical/<our test calendar ics file> GET /calendar/ical/<our test calendar ics file> HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: <some cookie data> HTTP/1.x 200 OK Content-Type: text/calendar; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Fri, 01 Jan 1990 00:00:00 GMT Date: Mon, 21 Sep 2009 00:14:03 GMT Content-Encoding: gzip X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN Content-Length: 3421 Server: GFE/2.0 ---------------------------------------------------------- And this is our Seaside header... http://localhost:48199/seaside/Test GET /seaside/Test HTTP/1.1 Host: localhost:48199 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://localhost:48199/seaside Cookie: <some cookie data> HTTP/1.x 200 OK Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-Control: no-cache,must-revalidate Pragma: no-cache Content-Disposition: attachment;filename=events.ics Content-Type: text/calendar;charset=utf-8 Content-Length: 10944 ---------------------------------------------------------- WAKomCompressed>>convertResponse: aResponse | response gzip stream | response := super convertResponse: aResponse. response fieldAt: 'Content-Encoding' put: 'gzip'. gzip := GZipWriteStream on: (stream := RWBinaryOrTextStream on: ''). gzip nextPutAll: aResponse contents contents; close. ^ response contents: stream reset _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Detect the position of a page div
|
|
Is there a way to detect the offset of a given element on a page? The following simply returns '$this.offset()'.
html div id: 'bob'; script: ((html jQuery new draggable) onDrag: (html jQuery ajax script: [:s | s add: ((html jQuery: #bob) html: (html jQuery: #bob) offset)])); with: html jQuery this offset. Thanks! RS ps. If it helps, the purpose of this function is to let the server know if a map is being moved in order to buffer the new tiles; essentially, a tiling script (ie. Google maps). Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it out. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Detect the position of a page div
|
|
I don't understand what you are asking for, but what about something along?
html jQuery ajax callback: [ :left | Transcript show: left ] value: (html jQuery offset access: 'left'); callback: [ :top | Transcript show: top ] value: (html jQuery offset access: 'top') I am just adding a few convenience methods that should make things like this easier. Lukas 2009/9/22 Robert Sirois <[hidden email]>: > Is there a way to detect the offset of a given element on a page? The > following simply returns '$this.offset()'. > > html div > id: 'bob'; > script: ((html jQuery new draggable) onDrag: (html jQuery ajax > script: [:s | s add: ((html jQuery: #bob) html: (html jQuery: #bob) > offset)])); > with: html jQuery this offset. > > Thanks! > RS > > ps. > > If it helps, the purpose of this function is to let the server know if a map > is being moved in order to buffer the new tiles; essentially, a tiling > script (ie. Google maps). > > ________________________________ > Hotmail® has ever-growing storage! Don’t worry about storage limits. Check > it out. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Nemec
Thanks for the replies.
>Philippe... >It is unlikely that Drupal needs the content as gzip. >Have you compared the actual data? Does the format and encoding match? Yup. From what we can see the Google and our iCal files are the same format. I even added things like timezone headers (copied from Google), which are optional in the iCal spec. http://www.ietf.org/rfc/rfc2445.txt >Do you use CR LR and not just LF or CR? Both contain CR after the file is saved. >Are you sure content-length matches the lenght of your content? Yes. Content-Length: 10944 'C:\Documents and Settings\bnemec\My Documents\events.ics' asFilename contentsOfEntireFile size = 10944 >Have you tried returning the same thing as Google just without gzip (and a correct content-lenght). That's the only way I'm able to make it work at all, as a non-zipped file. Answering a gzip file is just not working yet ... I'd like to understand how to do that, even though it's not the likely cause of this problem. > Have you tried dropping the content-disposition header? Working on that one... as suggested by Boris. >Boris... >Aren't you sending it as an attachment and google simply serving it in the contents? >I see the following header in your response, but not in Google's? >I agree with Philippe, it's very unlikely that gzipping is your problem. >Content-Disposition: attachment;filename=events.ics I see. The browser responds to both the Google feed and our own by asking if you want to save or open the file, so I assumed that just answering the iCal data in HTML would not suffice. I tried using just 'html html: self iCalData', which the browser displayed in place (vs. an open or download option). It also did not work with Drupal. Is there another way to answer the iCal contents without the 'Content-Dispostion'? What other tool can I use to view the raw data feed from the Google iCal URL? Also, I'm not sure how robust the Drupal code is, which is why we tried the gzip download. It may just expect it. I can find not documentation on the internals or on the expected feed details. BTW: Sorry for posting the original question twice; had some email & Nabble problems. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
|
|
In reply to this post by Bob Nemec
>Boris,
>By the way, it might be easier to compare text files obtained with curl, >curl -iL http://www.google.com > google.txt >curl -iL http://www.microsoft.com > microsoft.txt Yes, this does show the Content-Dispostion difference. Google data is correctly in-lined. Our data has the <!DOCTYPE hmtl... header. Sounds like I need to understand how to properly answer the iCal datal. I can work on that. Thanks again, Bob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
|
|
In reply to this post by Bob Nemec
>Boris
>Quick search reveals something called #useGZipTransfer and >#useGZipTransfer:, perhaps you could just set that property on a Seaside >adaptor? If not, Apache proxying your Seaside server can do compression >for you (you may need to turn off HTTP chunking of responses). Our production Seaside is proxied by Apache, but for testing we just use Seaside server. I did turn off chuncking (wget was having issues with it on). I did see how #useGZipTransfer was referenced, but I don't understand how to set it. How do you set #useGZipTransfer: to true in a Seaside adaptor? Thanks, Bob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
RE: RE: iCal to Drupal requires Content-Encoding: gzip
|
|
Try:
SeasideHttpWriteHandler useGZipTransfer: true. I agree with Boris that most likely having the Content-Disposition header field(Content-Disposition: attachment) in the Http message with a simple body is a problem. Tamara Kogan Smalltalk development, Cincom Systems > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf > Of [hidden email] > Sent: Tuesday, September 22, 2009 10:46 AM > To: Seaside List > Subject: [Seaside] RE: iCal to Drupal requires Content-Encoding: gzip > > >Boris > >Quick search reveals something called #useGZipTransfer and > >#useGZipTransfer:, perhaps you could just set that property > on a Seaside > >adaptor? If not, Apache proxying your Seaside server can do > compression > >for you (you may need to turn off HTTP chunking of responses). > Our production Seaside is proxied by Apache, but for testing > we just use Seaside server. I did turn off chuncking (wget > was having issues with it on). > I did see how #useGZipTransfer was referenced, but I don't > understand how to set it. > How do you set #useGZipTransfer: to true in a Seaside adaptor? > Thanks, > Bob > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Nemec
>Try:
>SeasideHttpWriteHandler useGZipTransfer: true. ... >Tamara Kogan >Smalltalk development, >Cincom Systems Thanks. I was trying to set it in the context of a single WAResponse; I didn't think of changing the class value. Bob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
RE: RE: iCal to Drupal requires Content-Encoding: gzip
|
|
You can also set
SeasideTransport class>>defaultWriterBlock: aBlock Where: aBlock ^[ SeasideHttpWriteHandler new shouldChunk: false; useGZipTransfer: true; yourself. ] Tamara Kogan Smalltalk development, Cincom Systems > -----Original Message----- > From: [hidden email] > [mailto:[hidden email]] On Behalf > Of [hidden email] > Sent: Tuesday, September 22, 2009 11:17 AM > To: Seaside List > Subject: [Seaside] RE: iCal to Drupal requires Content-Encoding: gzip > > >Try: > >SeasideHttpWriteHandler useGZipTransfer: true. ... > >Tamara Kogan > >Smalltalk development, > >Cincom Systems > Thanks. I was trying to set it in the context of a single > WAResponse; > I didn't think of changing the class value. > Bob > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Detect the position of a page div
|
|
In reply to this post by Lukas Renggli
I was hoping to display the offset values of a draggable element within itself.
renderContentOn: html html div id: 'bob'; script: ((html jQuery new draggable) onDrag: ( (html jQuery ajax script: [:s | s add: ((s jQuery: #bobLeft) html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'left']))]), (html jQuery ajax script: [:s | s add: ((s jQuery: #bobTop) html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'top']))]) ) ); with: [ html div id: 'bobLeft'; with: 'left'. html div id: 'bobTop'; with: 'top'. ]. This code doesn't really work either, as it just displays the js function within the callback. I think I'm missing the part where it needs to return something? Btw, I got your code to run fine, thank you. RS > Date: Tue, 22 Sep 2009 10:14:48 +0200 > Subject: Re: [Seaside] Detect the position of a page div > From: [hidden email] > To: [hidden email] > > I don't understand what you are asking for, but what about something along? > > html jQuery ajax > callback: [ :left | Transcript show: left ] > value: (html jQuery offset access: 'left'); > callback: [ :top | Transcript show: top ] > value: (html jQuery offset access: 'top') > > I am just adding a few convenience methods that should make things > like this easier. > > Lukas > > 2009/9/22 Robert Sirois <[hidden email]>: > > Is there a way to detect the offset of a given element on a page? The > > following simply returns '$this.offset()'. > > > > html div > > id: 'bob'; > > script: ((html jQuery new draggable) onDrag: (html jQuery ajax > > script: [:s | s add: ((html jQuery: #bob) html: (html jQuery: #bob) > > offset)])); > > with: html jQuery this offset. > > > > Thanks! > > RS > > > > ps. > > > > If it helps, the purpose of this function is to let the server know if a map > > is being moved in order to buffer the new tiles; essentially, a tiling > > script (ie. Google maps). > > > > ________________________________ > > Hotmail® has ever-growing storage! Don’t worry about storage limits. Check > > it out. > > _______________________________________________ > > seaside mailing list > > [hidden email] > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Ready for Fall shows? Use Bing to find helpful ratings and reviews on digital tv's. Click here. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Detect the position of a page div
|
|
There is a bit too much nested AJAX going on for me ;-)
> script: ((html jQuery new draggable) onDrag: ( > > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobLeft) > html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'left']))]), > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobTop) > html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'top']))]) > > ) > ); The message #html: expects aRenderable, such as a block or a string of HTML, something that is generated by Seaside on the server. In your case you just display the script and that is what you see in the browser. If you replace #html with #text: and remove the roundtrip to the server this should already work: (html jQuery ajax script: [:s | s add: ((s jQuery: #bobLeft) text: ((s jQuery: #bob) offset access: 'left'))]), (html jQuery ajax script: [:s | s add: ((s jQuery: #bobTop) text: ((s jQuery: #bob) offset access: 'top'))]) Now it displays the coordinates, but very much delayed as the script makes two round-trips to the server whenever you move the draggable element. In fact, this round-trip is not needed at all. If you remove all AJAX code the script becomes much simpler and faster. Furthermore, if you use the navigation facilities of jQuery you don't need any of the IDs and the script becomes: html div script: (html jQuery new draggable onDrag: ((html jQuery this find: ':first') text: (html jQuery this offsetLeft)) , ((html jQuery this find: ':last') text: (html jQuery this offsetTop))); with: [ html div: 'left'; div: 'top' ] Note, I use #offsetLeft and #offsetTop here, two methods I added to jQuery this morning after your post. You might want to update to the latest code, or replace the calls with the old code #access: Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Nemec
>>Boris,
>>By the way, it might be easier to compare text files obtained with curl, >>curl -iL http://www.google.com > google.txt >>curl -iL http://www.microsoft.com > microsoft.txt >Yes, this does show the Content-Dispostion difference. Google data is correctly in-lined. Our data >has the <!DOCTYPE hmtl... header. >Sounds like I need to understand how to properly answer the iCal datal. I can work on that. Using... response := Seaside.WAResponse document: self iCalText mimeType: 'text/calendar;charset=utf-8'. response doNotCache. self session returnResponse: response. ...curl says were answering... HTTP/1.1 200 OK Expires: Sat, 1 Jan 2095 07:00:00 -0500 Expires: Wed, 11 Jun 1980 08:00:00 -0400 Cache-control: no-cache,must-revalidate Pragma: no-cache Content-type: text/calendar;charset=utf-8 Content-length: 10944 BEGIN:VCALENDAR <...> Drupal is still not happy. But at least this looks cleaner than what I had before. A bit more to do. Bob _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
Re: RE: iCal to Drupal requires Content-Encoding: gzip
|
|
In reply to this post by Bob Nemec
Are you sure its actually utf8? I had to put some nasty hacks in VW/Seaside to get that to work in both 7.6 and 7.7... Just a thought, if your content is all ascii then it makes no difference. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: iCal to Drupal requires Content-Encoding: gzip
|
|
In reply to this post by Bob Nemec
[hidden email] wrote:
> Content-type: text/calendar;charset=utf-8 > Content-length: 10944 > > BEGIN:VCALENDAR > <...> > > Drupal is still not happy. But at least this looks cleaner than what I had before. > A bit more to do. Try looking for blank characters after the '>' tag delimiters. Also, use octal dump ("od") to spot the exact differences between that one that works, and the one that doesn't. -- Yanni _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: iCal to Drupal requires Content-Encoding: gzip
|
|
In reply to this post by Bob Nemec
2009/9/22, [hidden email] <[hidden email]>:
> Thanks for the replies. > >>Philippe... >>It is unlikely that Drupal needs the content as gzip. >>Have you compared the actual data? Does the format and encoding match? > Yup. From what we can see the Google and our iCal files are the same > format. > I even added things like timezone headers (copied from Google), which are > optional in the iCal spec. > http://www.ietf.org/rfc/rfc2445.txt > >>Do you use CR LR and not just LF or CR? > Both contain CR after the file is saved. Bad, bad, BAD. The spec says CRLF. >>Are you sure content-length matches the lenght of your content? > Yes. Content-Length: 10944 > 'C:\Documents and Settings\bnemec\My Documents\events.ics' asFilename > contentsOfEntireFile size = 10944 > >>Have you tried returning the same thing as Google just without gzip (and a >> correct content-lenght). > That's the only way I'm able to make it work at all, as a non-zipped file. Good. Then there's likely a problem with your iCal. Happy debugging. > Answering a gzip file is just not working yet ... I'd like to understand how > to do that, even though it's not the likely cause of this problem. If you send gzip, then you need to indicate that using the Content-Encoding header. How else would the user agent know it's gzip. >> Have you tried dropping the content-disposition header? > Working on that one... as suggested by Boris. > >>Boris... >>Aren't you sending it as an attachment and google simply serving it in the >> contents? >>I see the following header in your response, but not in Google's? >>I agree with Philippe, it's very unlikely that gzipping is your problem. >>Content-Disposition: attachment;filename=events.ics > I see. The browser responds to both the Google feed and our own by asking > if you want to save or open the file, so I assumed that just answering the > iCal data in HTML would not suffice. I tried using just 'html html: self > iCalData', which the browser displayed in place (vs. an open or download > option). It also did not work with Drupal. > > Is there another way to answer the iCal contents without the > 'Content-Dispostion'? > What other tool can I use to view the raw data feed from the Google iCal > URL? > > Also, I'm not sure how robust the Drupal code is, which is why we tried the > gzip download. If you think the code is not super robust then adding gzip to the mix is likely going to make the problem worse. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Detect the position of a page div
|
|
In reply to this post by Lukas Renggli
Dang! That's cool. I was hoping the callbacks would return something for "#html:". Thanks for the help! Ill play around with it when I get home.
So "#text:" doesn't expect the same thing as "#html:" then? Oh, also. I recall a comment somewhere that you can only register one callback on a class? Does that only apply to seaside components? Thanks! RS > Date: Tue, 22 Sep 2009 19:20:54 +0200 > Subject: Re: [Seaside] Detect the position of a page div > From: renggli@gmail.com > To: seaside@lists.squeakfoundation.org > > There is a bit too much nested AJAX going on for me ;-) > > > script: ((html jQuery new draggable) onDrag: ( > > > > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobLeft) > > html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'left']))]), > > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobTop) > > html: (s jQuery ajax callback: [(s jQuery: #bob) offset access: 'top']))]) > > > > ) > > ); > > The message #html: expects aRenderable, such as a block or a string of > HTML, something that is generated by Seaside on the server. In your > case you just display the script and that is what you see in the > browser. > > If you replace #html with #text: and remove the roundtrip to the > server this should already work: > > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobLeft) text: > ((s jQuery: #bob) offset access: 'left'))]), > (html jQuery ajax script: [:s | s add: ((s jQuery: #bobTop) text: > ((s jQuery: #bob) offset access: 'top'))]) > > Now it displays the coordinates, but very much delayed as the script > makes two round-trips to the server whenever you move the draggable > element. In fact, this round-trip is not needed at all. If you remove > all AJAX code the script becomes much simpler and faster. Furthermore, > if you use the navigation facilities of jQuery you don't need any of > the IDs and the script becomes: > > html div > script: (html jQuery new draggable onDrag: > ((html jQuery this find: ':first') text: (html jQuery this offsetLeft)) , > ((html jQuery this find: ':last') text: (html jQuery this offsetTop))); > with: [ html div: 'left'; div: 'top' ] > > Note, I use #offsetLeft and #offsetTop here, two methods I added to > jQuery this morning after your post. You might want to update to the > latest code, or replace the calls with the old code #access: > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Bob Nemec
>> Content-type: text/calendar;charset=utf-8
I think we're good, now. I had made the mistake of using VW to check the saved ics files before,
>> Content-length: 10944 >> >> BEGIN:VCALENDAR >> <...> >> >> Drupal is still not happy. But at least this looks cleaner than what I had before. >> A bit more to do. >Try looking for blank characters after the '>' tag delimiters. > >Also, use octal dump ("od") to spot the exact differences between that >one that works, and the one that doesn't. and it changed the Google cr, lf to a single cr. I should know better. So now I answer an massaged file with cr, lf. This is the output from hexdump -C <file> (octal dump is just too painful). We're looking at Drupal diagnostics now. Every other web tool is happy with our data. Ours... 000000e0 0a 0d 0a 42 45 47 49 4e 3a 56 43 41 4c 45 4e 44 |...BEGIN:VCALEND| 000000f0 41 52 0d 0a 50 52 4f 44 49 44 3a 2d 2f 2f 43 68 |AR..PRODID:-//Ch| 00000100 65 72 6e 69 61 6b 20 53 6f 66 74 77 61 72 65 2f |erniak Software/| 00000110 2f 4d 45 2f 2f 45 4e 0d 0a 56 45 52 53 49 4f 4e |/ME//EN..VERSION| 00000120 3a 32 2e 30 0d 0a 42 45 47 49 4e 3a 56 54 49 4d |:2.0..BEGIN:VTIM| Google... 00000140 0a 0d 0a 42 45 47 49 4e 3a 56 43 41 4c 45 4e 44 |...BEGIN:VCALEND| 00000150 41 52 0d 0a 50 52 4f 44 49 44 3a 2d 2f 2f 47 6f |AR..PRODID:-//Go| 00000160 6f 67 6c 65 20 49 6e 63 2f 2f 47 6f 6f 67 6c 65 |ogle Inc//Google| 00000170 20 43 61 6c 65 6e 64 61 72 20 37 30 2e 39 30 35 | Calendar 70.905| 00000180 34 2f 2f 45 4e 0d 0a 56 45 52 53 49 4f 4e 3a 32 |4//EN..VERSION:2| _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Bob Nemec
|
Re: Detect the position of a page div
|
|
In reply to this post by Robert Sirois
> So "#text:" doesn't expect the same thing as "#html:" then?
Nop, but you are right. Maybe that's not quite right what Seaside does here? > Oh, also. I recall a comment somewhere that you can only register one > callback on a class? Does that only apply to seaside components? No, this has nothing to do with components. You can only register one primary callback for an ajax object, e.g. html jQuery ajax callback: [ ... ]; callback: [ ... ] " <-- wrong " does not make sense, because Seaside returns a response after processing the primary callback. However you can register as many secondary callbacks as you want, e.g. to serialize values to the server: html jQuery ajax " <-- correct " callback: [ :v1 | "this is a secondary callback" ] value: ....; callback: [ :v2 | "this is a secondary callback" ] value: ....; html: [ :h | "this is a primary callback that generates html, internally it calls #callback:" ]; ... Note that the primary callback is always evaluated last, whereas the secondary callback are evaluated before in order they were defined. Hope this helps? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |