seaside-dev October 2008

seaside-dev@lists.squeakfoundation.org

17 participants
230 discussions

Re: [Seaside-dev] basicNew
by Avi Bryant 07 Jan '09

07 Jan '09

On Mon, Sep 29, 2008 at 12:43 PM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: > Avi> Change super to self in this method, and (given the rest of the code > Avi> in my example) you would have infinite recursion. > > I didn't see that you had a local initialize. If you had, then > *it* should have been the one to have super initialize, since the local > initialize is superceding it by extension. And what would the rest of that method look like? What would the other methods look like? This is a fairly intricate convention and it doesn't make sense to look at an individual piece of it in isolation. If you're arguing that the local initialize should call its super method, can you also show what the rest of this (tiny) example would look like so I can understand the entire control flow you're proposing? Avi

6 14

Issue with subStrings:
by Gerhard Obermann 31 Oct '08

31 Oct '08

Hi! I am currently using the method "subStrings:" in Seaside 2.9. This seems to be a little problem, because the semantics on Squeak and GemStone are different. And AFAIK its not available on other platforms (VW) by default. Which are the options: - Change Squeak or GemStone semantics => Probably not ! - Define new Seaside specific subStrings: method - Rewrite those methods to avoid using subStrings: ... Any other ideas Cheers Gerhard

5 5

Seaside-Squeak-Development-pmm.37 and friends
by Philippe Marschall 30 Oct '08

30 Oct '08

Hi Yesterday I had time from 0530 to 1415 to work. Check out /seaside/status. Currently the plan is to allow for editing the changeable values as well. The problem is that it's quite big in terms of code now. Sorry I'm kinda in hurry and don't have time to merge. Cheers Philippe

3 3

ping
by Philippe Marschall 29 Oct '08

29 Oct '08

this is a test if the list still works please pong Cheers Philippe

8 7

Some Feature Requests
by Keith Hodges 29 Oct '08

29 Oct '08

I haven't looked at 2.9 yet but I would like to request a couple of essentials. 1. Please could you at least add a properties dictionary to WASession. This is extremely useful, and allows multiple features to be added to Seaside as plugins/addons/helpers without subclassing WASession. 2. I would like you guys to review the helpers in SeasideJetsam, this kind of thing should be included as standard, again they work very well indeed. i.e. add shore components support to any seaside app, magma, comet, keep alive, (glorp from VW equivalent of helpers) etc etc. 3. Please could you add support for post request processing. i.e. enable code to run after the server has sent the request to the browser, in the same thread. e.g. removeItem: item id: id on: script script effect id: id; dropOut. "remove item from the database, a) without slowing the UI interaction b) within the scope of this session/db session etc" self session postServeBlocks add: [ self removeItem: item ] . comments requested, thanks in advance Keith

3 8

Issue 224 in seaside: per-session minimum cache lifetime
by codesite-noreply＠google.com 28 Oct '08

28 Oct '08

Issue 224: per-session minimum cache lifetime http://code.google.com/p/seaside/issues/detail?id=224 Comment #1 by jfitzell: The feature referred to in the last paragraph (passing both the object and the key into the plugins) has already been implemented. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 224 in seaside: per-session minimum cache lifetime
by codesite-noreply＠google.com 28 Oct '08

28 Oct '08

Issue 224: per-session minimum cache lifetime http://code.google.com/p/seaside/issues/detail?id=224 New issue report by jfitzell: This feature existed previously in 2.8 but has disappeared from 2.9 at the moment as a result of moving expiry code off of WASession and onto WACache. I can see doing this through some combination of RequestFilters and cache plugins but I still can't get my head around what a good interface for it would like. This is the original discussion from seaside-dev: On Fri, Sep 19, 2008 at 7:14 AM, Julian Fitzell <jfitzell(a)gmail.com> wrote: > On Fri, Sep 19, 2008 at 1:54 AM, Ramon Leon <ramon.leon(a)allresnet.com> wrote: >>> I haven't seen the code, but as a use case, I'd like >>> to be able to say: >>> >>> self session expireInNoLessThanSeconds: (86400 * 7). >>> >>> to make a particular session have a long expiry, if it >>> contains a callback URL >>> to validate a user or something. I don't think there's an easy way >>> to decide expiry on a per-session basis. >>> >>> -- >>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - >> >> You can do that now fairly easily... >> >> self session timeoutSeconds: (86400 * 7). >> >> I haven't seen 2.9, but that works in 2.8, I change my session timeout >> dynamically when I detect an ajax request to kick up the timeout because >> that tells me it's a real user and not a spider. > > Well, I'll have just broken that in this code. But I'll ponder the > best way to continue supporting it... > > The question is how you should interface with the cache when its > strategies are pluggable... So, I don't quite have an answer yet but I had some thoughts during the day today that I thought I would share in case they prompt further thoughts from someone else. It occurs to me that there are two different concepts of expiry here. One is (a)"can I access the session or has it expired?" and the other is (b)"is the session registered in the cache or has the cache unregistered it?". Obviously the two are related (if it's not registered in the cache, you can't access it) but they're not quite the same. You could implement all kinds of funky per-session expiry policies of type (a) by using the new RequestFilters and attaching them to the session. This obviously depends on the cache keeping your session around long enough, though. You might get away with a suitably long cache expiry time, but I think I will also change the expiry policies so they receive both the object and the key. That way you could write a policy that depended on having stored objects with a particular interface and you could use that to ask the object for details such as the length of time it would like to remain alive. That might at least give the flexibility to implement such a system, even if it ended up seeming too hardcoded to provide out of the box. Julian Issue attributes: Status: Accepted Owner: ---- Labels: Type-Feature Priority-Medium Version-Seaside2.9 -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 223 in seaside: handler statistics request filter
by codesite-noreply＠google.com 28 Oct '08

28 Oct '08

Issue 223: handler statistics request filter http://code.google.com/p/seaside/issues/detail?id=223 New issue report by jfitzell: Would be nice to have a request filter that kept track of when the request handler was last accessed, how many times it has been accessed, and so on. Issue attributes: Status: Accepted Owner: ---- Labels: Type-Feature Priority-Low -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 176 in seaside: deprecate WAExpiringHandler protocol
by codesite-noreply＠google.com 28 Oct '08

28 Oct '08

Issue 176: deprecate WAExpiringHandler protocol http://code.google.com/p/seaside/issues/detail?id=176 Comment #6 by jfitzell: I documented the rest on http://seaside.st/documentation/migration/28to29 as follows: The session cache on WAApplication has been made pluggable so expiry behaviour is no longer contained within WASession itself. Methods like #lastAccess, #secondsSinceLastAccess, #timeoutSeconds, #timeoutSeconds:, and #isActive currently do not exist. We are thinking about how best to provide this functionality in later alpha releases but in the meantime you will have to do without them. Sessions will also now receive #unregistered rather than #expired when they are removed from the cache. -------------------- I think that's all that can be done for the moment so I'm closing this. Issue attribute updates: Status: Fixed Owner: jfitzell -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 222 in seaside: do a thorough run of all functional tests for 2.9 alpha
by codesite-noreply＠google.com 28 Oct '08

28 Oct '08

Issue 222: do a thorough run of all functional tests for 2.9 alpha http://code.google.com/p/seaside/issues/detail?id=222 New issue report by jfitzell: . Issue attributes: Status: Accepted Owner: ---- Labels: Type-Task Priority-Critical Version-Seaside2.9 Milestone-2.9alpha -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev October 2008