seaside-dev August 2010

seaside-dev@lists.squeakfoundation.org

11 participants
12 discussions

New contributions
by Avi Shefi 11 Sep '10

11 Sep '10

Hi, I'm new to Seaside development, and would like to start contributing. I have read the online Seaside book, which shows how to use Seaside, but doesn't depict how to start developing it. After reviewing the "BiteSize" tasks in the issue tracker I'm still wondering which easy task to begin with should I tackle first. Any suggestions? (please note that I will need some guidance, if possible) [image: Heartland] www.salepoint.co.il, www.redpoint.co.il *Avi Shefi* Co-Founder & CTO *Mobile*: +972 54 5331705, *Email*: avishefi(a)gmail.com

2 5

Seaside 3.0 and Grease 1.0
by Dale Henrichs 28 Aug '10

28 Aug '10

Julian, I haven't seen an announcement but I've seen that the version numbers have been bumped for both of these guys ... yet changes have continued flowing in and I've seen no announcement ... At first blush I thought I'd missed the announcement, but now I'm guessing that the version numbers have been changed, while the 3.0/1.0 are still under development, which means they're technically still rc? Dale

2 1

Re: Seaside Development
by Lukas Renggli 27 Aug '10

27 Aug '10

Hi Avi, Please submit your changes to the mailing-list and/or bug-tracker first, so that we can learn about your contributions. We are happy to review and merge your improvements, and will eventually add you to the Seaside developers group on SqueakSource. If you have any questions to the contribution process, please ask on the developer mailing-list. Lukas On 27 August 2010 14:17, Avi Shefi <avishefi(a)gmail.com> wrote: > > Hi, > My name is Avi Shefi, I have just joined SqueakSource. > I'm interested in contributing code to Seaside, and read on the Seaside webpages that I need to contact an admin to be added to the group of Seaside developers. > > > Please add me to the group. Additionally, I'd be glad if someone could help me in getting started with Seaside and contributing code to it. > > www.salepoint.co.il, www.redpoint.co.il > Avi Shefi > Co-Founder & CTO > Mobile: +972 54 5331705, Email: avishefi(a)gmail.com -- Lukas Renggli www.lukas-renggli.ch

1 0

Automatic registration of children?
by Nicolas Petton 19 Aug '10

19 Aug '10

Hi, Maybe I don't know Seaside enough and the following doesn't make sense, but just in case.. Back when I was playing around with Seaside, I always found quite annoying to have to implement #children everywhere in my components and feared to break the back button somewhere. We recently needed a #children like method in Iliad, so I thought about other ways to do it. The idea is to use a dynamic variable (let's call it WACurrentComponent). When rendering a component, we register can children with something like: renderOn: aRenderer self withChildrenRegistrationDo: [ ... ...] withChildrenRegistrationDo: aBlock children := OrderedCollection new. WACurrentComponent value ifNotNil: [:parent | parent registerChild: self]. WACurrentComponent use: self during: aBlock registerChild: aComponent children add: aComponent As I said, it works fine for us but maybe it won't for Seaside :) Cheers! Nicolas

3 5

Re: [Seaside Issues] Issue 594 in seaside: #style methods don't work then session cookies are enabled
by Julian Fitzell 19 Aug '10

19 Aug '10

#doesHandlerSupportCookies: (and note there's a typo in the method you created) seems really ugly. I've felt for a long time that having non-sessions in the Application's cache is pretty gross and this is just yet another example of why. I think we need to give some thought to the design here... Julian On Fri, Aug 13, 2010 at 1:05 PM, <seaside(a)googlecode.com> wrote: > Updates: > Status: Fixed > > Comment #2 on issue 594 by philippe.marschall: #style methods don't work > then session cookies are enabled > http://code.google.com/p/seaside/issues/detail?id=594 > > Name: Seaside-Core-pmm.655 > Author: pmm > Time: 13 August 2010, 2:02:03 pm > UUID: 4e7d671c-eb15-4291-8213-70e7a319c8a2 > Ancestors: Seaside-Core-pmm.654 > > - Issue 594: #style methods don't work then session cookies are enabled > - http://code.google.com/p/seaside/issues/detail?id=594 > > Name: Seaside-Session-pmm.133 > Author: pmm > Time: 13 August 2010, 2:02:55 pm > UUID: 20c413c9-f088-4b94-a361-6496656cd575 > Ancestors: Seaside-Session-jf.132 > > - Issue 594: #style methods don't work then session cookies are enabled > - http://code.google.com/p/seaside/issues/detail?id=594 > > Name: Seaside-Tests-Core-pmm.198 > Author: pmm > Time: 13 August 2010, 2:03:37 pm > UUID: ad1f5f9f-d5d8-419a-a015-28b65af5af5b > Ancestors: Seaside-Tests-Core-pmm.197 > > - Issue 594: #style methods don't work then session cookies are enabled > - http://code.google.com/p/seaside/issues/detail?id=594 > > Name: Seaside-Tests-Session-pmm.41 > Author: pmm > Time: 13 August 2010, 2:04:19 pm > UUID: 95ec60c6-1e39-4ce0-a985-b6f4d82bdf8b > Ancestors: Seaside-Tests-Session-pmm.40 > > - Issue 594: #style methods don't work then session cookies are enabled > - http://code.google.com/p/seaside/issues/detail?id=594 > > > _______________________________________________ > issues mailing list > To unsubscribe, email issues-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/issues >

1 0

OAuth/Twitter demo in Squeak
by Andreas Raab 14 Aug '10

14 Aug '10

Hi - I was playing with OAuth authentication and in the process decided to test it against Twitter and since it's kind of fun, I thought I'd share it with the rest of the world. You can run the (very simple) demo here: http://ardemo.seasidehosting.st/seaside/twitter All it does is after you log in via Twitter it shows you the account info that Twitter shares with the app and allows you to tweet a little. The OAuth part itself is now integrated in WebClient's suite of auth methods and the little Twitter demo is available in http://www.squeaksource.com/ar.html and can be installed via (Installer ss project: 'ar') install: 'Twitter-Squeak'. Since I found OAuth to be a pretty major PITA I hope that this example will prove helpful for people who have to deal with this stuff. Lastly, a Seaside question that came up in the above: Part of the OAuth process requires passing a specific callback url to the remote site (which is the url the user gets redirected to after authentication was successful). Since I couldn't figure out how to obtain the url otherwise, I've been stashing it away in a rendering method (since there's access to the rendering context's callback store) like here: renderLoginPageOn: html "Set up the callback url for Twitter to return to" callback := WAActionCallback on: [self twitterCallback]. url := html actionUrl copy addField: (html callbacks store: callback). "We need the host and the scheme here; the scheme is guesswork" urlString := 'http://', host, '/', url asString. oauthParams at: 'oauth_callback' put: urlString encodeForHTTP. and then later the callback is passed to Twitter and the user sent back to the app. This works, but I'm wondering if that's the right thing to do, and if not, how one would set up and register such a callback url outside of rendering. Cheers, - Andreas

2 2

tracking sessions by ssl session id?
by Philippe Marschall 12 Aug '10

12 Aug '10

Hi Having the session id in the URL is a problem in some cases so I was wondering whether it would be possible to use the SSL session id as an alternative to cookies. Before starting any work: - Are there any reasons why this is a terrible idea? - Is there a way to get the SSL session id over mod_proxy? - Which server adapters besides AJP support getting the SSL session id? SqueakSSL/WebClient? SCGI? FastCGI? Swazoo? OpenTalk? Cheers Philippe

2 1

Comet request handling / Ajax performance
by Andreas Raab 12 Aug '10

12 Aug '10

Hi - I have a couple of questions about Comet request handling and related performance issues. Comet currently insists on having a subclass of WAStreamedResponse but if one looks at the code more closely it is pretty clear that there's a bunch of unneeded complexity here. It seems to me that what Comet wants is access to the stream so it can push the data; but since the Comet request's life cycle is such that it never returns to the caller, the use of WAStreamedResponse is quite simply overkill. The same result can be achieved by having a WAResponse return a suitable #cometStream (i.e., the external socket stream to write data to) and prevent WABufferedResponse from inserting the Content-Length header when pushing out the initial response. At this point, any subclass of WAResponse that can provide a suitable cometStream is capable of supporting Comet. I've implemented this as a proof of concept in a subclass of WABufferedResponse (see attached CometRequests.cs) that can be used by any server adaptor that has a SocketStream available, such as Comanche. You might wonder why I care about this. Simply put: Ajax response times. I've been trying to see if one can get interactive update rates using Ajax updaters and/or Comet but the design of WABufferedResponse is such that that it pretty much forces the server to close the connection after each request. Which kills all the performance for Ajax requests since Ajax performance pretty much exclusively relies on persistent HTTP connections (in my experiments the performance drops from a nice steady 50 req/sec using a persistent HTTP connection to 1 req/sec when the connection is closed). I'm actually a little surprised that nobody has complained yet about the abysmal performance of Ajax :-) And of course this only gets worse when you do it over https which I eventually intend to do. So, right now the alternative is that your server will EITHER support Comet OR efficient Ajax updates but not both. I can almost certainly work my way around this for WebServer but what I'm curious about is if people here think this should be fixed in Seaside in general or not. It depends a little on how you value both Comet and Ajax and how important wide and efficient support for either one is. I won't invest any more time in this for now, but there are a couple of obvious further simplifications given that WAStreamedResponse appears to be unused outside of Comet, and of course WACometResponse could be trivially folded into WABufferedResponse by pushing the cometStream up. For comparison, I'm also attaching my little Ajax benchmark. If you run it with WAWebServerAdaptor you should see a nice steady 50 req/secs whereas all other adaptors drop to about 1 req/sec. Cheers, - Andreas

4 8

Seaside-REST properly package-ized
by Philippe Marschall 08 Aug '10

08 Aug '10

Hi Seaside-REST has been properly package-ized into Core, Tests and Pharo [1]. The platform specific package is required for the pragma based configuration. I hope that turn out to be a good idea, not merely something that seemed like a good idea ;-) [1] http://www.squeaksource.com/Seaside30Addons Cheers Philippe

1 0

GRCodecStream>>tab
by Norbert Hartl 04 Aug '10

04 Aug '10

I try to make a tool of mine more mature by utilizing grease for it. But some tools I use like Sixx use tab: to indent XML in a stream. So I'm wondering why GRCodecStream has GRCodecStream>>tab for a single tab but not GRCodecStream>>tab: for multiple. What is the rationale of the decision to include one and not the other? thanks, Norbert

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev August 2010