seaside-dev January 2009

seaside-dev@lists.squeakfoundation.org

16 participants
435 discussions

Re: encoded stream
by Julian Fitzell 06 Feb '09

06 Feb '09

(moving this to the list) On Sat, Jan 24, 2009 at 3:16 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > On Sat, Jan 24, 2009 at 1:14 PM, Julian Fitzell <julian(a)fitzell.ca> wrote: >> Philippe says the decoding needs to be done based on the same setting >> as the encoding (makes sense) so if we are encoding based on an >> Application setting, we need to be decoding based on the same setting. >> I guess this means putting raw data in the Request object and >> specifying a Codec when you read from it (or just configuring it with >> one as it goes by so things further down the handling pipeline use >> that encoding automatically). All seems a little gross... > > Then I wonder why is there a char-set setting in the application at > all? Is there a reason to set it to something different than the > server adaptor? As best as I can understand, the Codec is supposed to be a configuration of what the encoding is *guaranteed* to be and the setting in the Application is what encoding is *reported*. By specifying a NullCodec, you are making no guarantee (you just give and take whatever the data is), but still might want to report that it is UTF-8 because that's what you think it is and you're going to just deal with it not working if not. Personally, though, while I sort of understand the logic behind this, I think this is a major source of confusion for people (it certainly is for me). And since we don't know for sure most of the time what encoding is used in a request, it isn't really a guarantee anyway. I think (and I'm really not certain, I'm just thinking aloud here, so go easy on me!!) I would rather see something where you specified an external/internal encoding *pair* in the configuration and an appropriate Codec was selected based on that. For example: UTF-8/Smalltalk: + Response data is assumed to be provided in Smalltalk encoding and is converted to UTF-8. + UTF-8 is reported to the browser as the encoding. + Request data is assumed to be UTF-8 unless an encoding is specified in the request. + Data is converted to Smalltalk encoding from either UTF-8 or whatever is specified. Latin-1/Smalltalk: + Same as above but read "Latin-1" instead of "UTF-8" UTF-8/UTF-8: + Response data is assumed to be provided in UTF-8 encoding. Since that is the same as the external encoding, no conversion is therefore necessary. + UTF-8 is reported to the browser. + Request data is assumed to be UTF-8 unless an encoding is specified in the request. + No conversion is needed unless a different encoding was specified in the request, in which case the data is converted to UTF-8. And so on... Basically, when moving data in either direction, you: + assume the default encoding specified on input side unless told otherwise; and + convert to the encoding specified on the output side (if different). It might be that these would be better specified as some kind of encoding *policy* and the specific Codec selected as needed based on what two encodings you actually end up with. But I think this makes it much clearer than the current implementation what the different options are doing and might actually help people to make decisions based on their real needs. Given the lack of understanding around this, just saying "use WAKom" or "use WAKomEncoded" seems to be a bit opaque. As for whether the setting is on the Application or the ServerAdaptor, I think the above works in either case, but at least everything can use the same setting, removing a source of confusion. Obviously it would be nice to have a per-application setting so you can have (legacy?) applications with one behaviour alongside applications with another. But since you can now easily have multiple ServerAdaptors running, this is somewhat less of an issue. (note the above doesn't deal with URL encoding - I don't want to make this email any longer by delving into that at the instant) Thoughts? Julian

3 12

exception handler instance creation
by Julian Fitzell 04 Feb '09

04 Feb '09

I started writing some docs on the new exception handler interface. In doing so, I realized I hated the method name #exceptionToCatch so I changed that and then remembered that Lukas was asking for the exception handlers to implement #handles: and #, so that they can be used in place of an ExceptionSet as defined in the ANSI spec. So I did this too. This raised again the question of when an instance of our exception handlers should be created. If you look at the current implementation of #handleExceptionsDuring:context:, you will see that an instance is not actually created until an exception that this class handles is signaled. This requires a temporary variable and means that the instance does not have a chance to indicate whether it wants to handle the exception or not (whether they is a required feature or not is perhaps debatable... I dunno). The only reason I did this was to avoid the overhead of creating the instance when we don't need it but I'm wondering if this was a premature optimization and the implementation would be simpler if I didn't do it. #handleExceptionsDuring:context: would just become: #handleExceptionsDuring: aBlock context: aRequestContext ^ (self context: aRequestContext) handleExceptionsDuring: aBlock And on the instance side we would have: #handleExceptionsDuring: aBlock ^ aBlock on: self do: [ :exception | [ self handleException: exception ] on: Error do: [ :error | self internalError: error ] ] No temporary variable, instances can choose whether to handle exceptions if they want to, no risk of being unable to create an error handler when reporting an internal error. Am I right that this seems like the better option? Julian

4 8

[seaside commit] r180 - wiki
by codesite-noreply＠google.com 01 Feb '09

01 Feb '09

Author: WeybridgeWay Date: Fri Jan 30 15:58:03 2009 New Revision: 180 Modified: wiki/LoadOrder.wiki Log: Move Seaside-Flow to after Seaside-Continuation per email from Julian to the list. --James Modified: wiki/LoadOrder.wiki ============================================================================== --- wiki/LoadOrder.wiki (original) +++ wiki/LoadOrder.wiki Fri Jan 30 15:58:03 2009 @@ -26,12 +26,12 @@ * Seaside-Tests-Environment (for defects see Issue 319) = Traditional = + * Seaside-Squeak-Continuation + * Seaside-Squeak-Continuation * Seaside-Flow * Seaside-Tests-Functional * Seaside-Tests-Squeak-Functional * Seaside-Tests-Flow - * Seaside-Squeak-Continuation - * Seaside-Squeak-Continuation * Seaside-Squeak-Flow * Seaside-!WebTools * Seaside-Squeak-!WebTools

4 3

Seaside-Tests-ANSI Package
by Lukas Renggli 01 Feb '09

01 Feb '09

I wonder about the package Seaside-Tests-ANSI: It contains two test methods related to stream positioning in their own test case, while all the rest of the related ANSI stream test remain in the class WAPlatformTests in Seaside-Tests-Platform. I assume that this change was made because a single platform does not pass these two tests. Does that mean that because Squeak/Pharo is the only platform where WAPlatformTests>>#testReadStreamIsEmpty fails, this test has to be brushed under the carpet into Seaside-Tests-ANSI? This seems totally weird to me. We will soon end up with a packaging chaos and everybody will randomly move around methods depending on whether they pass or not. Not seeing that a test fails defeats the purpose of testing. This is cheating. In order of personal preference I see 3 possible solutions: 1. Move the 2 tests back to Seaside-Tests-Platform. 2. Move all the ANSI related tests to Seaside-Tests-ANSI. However, there is already an ANSI test-suite and I would like to avoid duplicating that effort (http://map1.squeakfoundation.org/sm/package/d7011055-4446-4b8e-b6da-e7e32d3…). 3. Delete the 3 tests #testReadStreamPosition, #testWriteStreamPosition and #testReadStreamIsEmpty, as they seem to test functionality that is not currently in use Seaside. This is at the risk that suddenly somebody uses these common methods and finds them broken on some platforms. Thoughts? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

3 4

Issue 310 in seaside: #inNewRenderLoopCall: broken with partial continuations
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Updates: Labels: -Priority-Medium Priority-High Milestone-2.9b1 Comment #1 on issue 310 by jfitzell: #inNewRenderLoopCall: broken with partial continuations http://code.google.com/p/seaside/issues/detail?id=310 (No comment was entered for this change.) -- 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 305 in seaside: move #nativeRequest to WARequestContext?
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Updates: Status: Accepted Comment #8 on issue 305 by jfitzell: move #nativeRequest to WARequestContext? http://code.google.com/p/seaside/issues/detail?id=305 Do you mean you'd rather store the native request in the property dictionary than in an instvar? If so, then I guess that is ok, though an instvar seems better to me. If not, I don't think that storing just the data from the native request in the property dictionary is the same. The native request object may have methods as well as data that the user wants to use. -- 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 248 in seaside: deal with dependencies from RenderLoop on Component
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Updates: Status: Invalid Comment #3 on issue 248 by jfitzell: deal with dependencies from RenderLoop on Component http://code.google.com/p/seaside/issues/detail?id=248 I'm retracting this statement. I don't think Component should need to depend on Canvas, but RenderLoop really does need to depend on Component and Session. It expects a root Component, understands root Decorations, and uses various Guides and Visitors to do its work. I don't think there's any way to avoid all those dependencies. -- 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 236 in seaside: look at returning responses
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Updates: Status: Fixed Comment #2 on issue 236 by jfitzell: look at returning responses http://code.google.com/p/seaside/issues/detail?id=236 This is fixed by the Response refactoring. A Response is now stored in the RequestContext by the ServerAdaptor and RequestHandlers are expected to modify that response. When the request handling finishes or a handler signal a ResponseNotification, the Response is taken out of the RequestContext and sent to the browser. -- 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 217 in seaside: WACollectionAttribute
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Comment #11 on issue 217 by jfitzell: WACollectionAttribute http://code.google.com/p/seaside/issues/detail?id=217 See also Issue 142 -- 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 198 in seaside: WAResponse should not depend on WAApplication
by codesite-noreply＠google.com 31 Jan '09

31 Jan '09

Updates: Status: Fixed Comment #3 on issue 198 by jfitzell: WAResponse should not depend on WAApplication http://code.google.com/p/seaside/issues/detail?id=198 Fixed by Response refactoring -- 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 January 2009