seaside-dev April 2010

seaside-dev@lists.squeakfoundation.org

13 participants
17 discussions

Load order test failures
by James Foster 24 May '10

24 May '10

We have five errors starting with Core that seem to be fixed by Kom! Presumably something needs to be moved from Kom to Grease and Core. James Loaded Grease-Core-jok.34.mcz Loaded Grease-Pharo-Core-jok.18.mcz Loaded Grease-Tests-Core-lr.49.mcz Loaded Grease-Tests-Pharo-Core-jok.7.mcz 383 run, 380 passes, 2 expected failures, 0 failures, 1 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 Loaded Seaside-Core-obi.630.mcz Loaded Seaside-Pharo-Core-lr.6.mcz Loaded Seaside-Tests-Core-lr.189.mcz Loaded Seaside-Tests-UTF8-lr.9.mcz Loaded Seaside-Tests-Pharo-Core-lr.9.mcz 816 run, 809 passes, 2 expected failures, 0 failures, 5 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 WAGenericCodecTest>>#testGenericCodecMacRoman WAGenericCodecTest>>#testGenericCodecUtf16be WAGenericCodecTest>>#testGenericCodecUtf16le WAEncoderSqueakTest>>#testEncodedLatin1Url ... Loaded Seaside-Email-lr.15.mcz Loaded Seaside-Tests-Email-lr.9.mcz Loaded Seaside-Pharo-Email-lr.6.mcz 1404 run, 1397 passes, 2 expected failures, 0 failures, 5 errors, 0 unexpected passes GRUtf8CodecTest>>#testCodecUtf8 WAGenericCodecTest>>#testGenericCodecMacRoman WAGenericCodecTest>>#testGenericCodecUtf16be WAGenericCodecTest>>#testGenericCodecUtf16le WAEncoderSqueakTest>>#testEncodedLatin1Url Loaded DynamicBindings-lr.13.mcz Loaded KomServices-lr.20.mcz Loaded KomHttpServer-lr.52.mcz Loaded Seaside-Adaptors-Comanche-pmm.57.mcz Loaded Seaside-Tests-Adaptors-Comanche-lr.13.mcz 1412 run, 1410 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes Loaded Comet-Core-lr.49.mcz Loaded Comet-Pharo-Core-lr.6.mcz Loaded Comet-Tests-Core-lr.10.mcz Loaded Comet-Examples-lr.18.mcz 1415 run, 1413 passes, 2 expected failures, 0 failures, 0 errors, 0 unexpected passes

1 2

Issue with WAAuthenticationFilter
by Reza Razavi 26 Apr '10

26 Apr '10

Hi, I'd like to report the following issue: 1) A PharoCore1.0rc1 - Latest update: #10505 image is deployed with the latest Seaside 3 and Pier 2 packages included. 2) The website is password protected. 3) Now, if login and password are removed using the config tool, without the corresponding WAAuthenticationFilter being also removed manually, then an exception is raised when trying to open a session. Hoping this helps, Regards, Reza

2 1

State backtracking with #states
by Joel Kitching 24 Apr '10

24 Apr '10

Hi there, I'm trying to use the state backtracking features by implementing #states in a WAComponent. However, I have noticed that it only seems to work when the WAComponent is the "top-level" component. i.e. if I try to implement #states in a WAComponent that is painted within the #renderContentOn: of another WAComponent, the #states message is never even called. Is this by design, or is this a bug, or could it be that I am doing something wrong in the first place? Regards, Joel

2 2

MathML support in Seaside?
by Nikolay Suslov 22 Apr '10

22 Apr '10

Hello, Is there exist any MathML <http://ru.wikipedia.org/wiki/MathML>implementation in Seaside? One attempt could be founded at http://www.squeaksource.com/DeveloperWorkspace (MathML-Test), but seems it does not work properly. Looking forward for help, Nikolay

1 1

Re: [Seaside Commits] Seaside 3.0: Grease-Tests-Pharo-Core-jok.7.mcz
by Lukas Renggli 20 Apr '10

20 Apr '10

I did not remove this method, because I was not sure if this method is really redundant to Pharo? >From what I understand this test checks if #testConvertToSmalltalkNewlines: can handle unicode characters beyond the byte-range (the euro symbol). Lukas On 16 April 2010 00:14, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > John O'Keefe uploaded a new version of Grease-Tests-Pharo-Core to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Grease-Tests-Pharo-Core-jok.7.mcz > > ==================== Summary ==================== > > Name: Grease-Tests-Pharo-Core-jok.7 > Author: jok > Time: 15 April 2010, 4:13:48 pm > UUID: 427a0773-62f9-f04a-ac30-cbb8db7bc866 > Ancestors: Grease-Tests-Pharo-Core-lr.6 > > remove redundant #testConvertToSmalltalkNewlines > > =============== Diff against Grease-Tests-Pharo-Core-lr.6 =============== > > Item was removed: > - ----- Method: GRPharoPlatformTest>>testConvertToSmalltalkNewlines (in category 'tests') ----- > - testConvertToSmalltalkNewlines > - | expected euro | > - expected := 'selector' , (String with: Character cr) , '"comment"'. > - self assert: expected = (GRPlatform current convertToSmalltalkNewlines: expected). > - self > - assert: > - expected = (GRPlatform current convertToSmalltalkNewlines: 'selector' , (String with: Character lf) , '"comment"'). > - self > - assert: > - expected > - = > - (GRPlatform current > - convertToSmalltalkNewlines: 'selector' , (String with: Character cr with: Character lf) , '"comment"'). > - euro := String with: (Character codePoint: 8364). > - self assert: (expected , euro) = (GRPlatform current convertToSmalltalkNewlines: expected , euro). > - self assert: (GRPlatform current convertToSmalltalkNewlines: nil) isNil! > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits > -- Lukas Renggli www.lukas-renggli.ch

3 2

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release
by Reza Razavi 17 Apr '10

17 Apr '10

At 16:51 17/04/2010, you wrote: >1. You should not #call: from within the answer handing. I don't call within the answer handling (please see the example below). > - Seaside 2.8 incorrectly performs the call, incorrectly aborts the >answer handling at a random point and resume the wrong answer handling >when the called component answers. > - Seaside 3.0 correctly throws an exception about the missing >marker. #call: is not possible at that point. Somehow surprised about Seaside 2.8, but well noted; thanks for the clarifications and excellent work. >2. You should not #call: from anywhere within the command execution of >Pier. I don't call from within the command execution of Pier either (I'll send a short email to the Pier mailing list to explain this). To see the exact issue that I talk about, please just change the following: PRContentsWidget >> onChangeContext: aContext super onChangeContext: aContext. self call: WAFlowConvenienceFunctionalTest new No change is necessary in #onAnswerCommand:. Then, if you point your browser to <http://localhost:8080/pier>http://localhost:8080/pier, you should get that Seaside error. My goal has basically been to clarify whether that's an expected behavior in Seaside 3.0 or a bug? FYI, I just double checked with the current distribution of Pier (Pharo0.1, Latest update: #10374), which looks like still based on Seaside 2.8, and the above change doesn't raises an error. On the contrary, the WAFlowTest application (that replaces WAFlowConvenienceFunctionalTest, since absent from that image) is launched and looks like working OK (although I perfectly believe you that this may have its own *internal* issues, as you described above). Regards, Reza

1 0

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release
by Reza Razavi 17 Apr '10

17 Apr '10

At 14:22 17/04/2010, Lukas Renggli wrote: >This seems very uncommon usage of Pier and #call:. Yes, but please note that the case that I posted is just designed to provide an example. Specifically, the #isKindOf: test on PRAddCommand is there just to limit the impact of my patch in that code. The real case has nothing at all with PRAddCommand per se. It is about launching the execution of my *composite commands*, in the same way that Pier launches its Commands, so as both types of commands cohabit seamless, while having a conceptually consistent and easy to maintained code. >The method #onAnswerCommand: is called >from the answer processing of Seaside, Yes, in general, but, in the case of #isQuick commands, Pier calls it directly (that's basically a shortcut; to reuse the code, as you know better than me 8-) ). And, this is also what I do in the case of my composite/meta-described commands (flow models). In none of these cases Seaside is answer processing, but handling callbacks as follows: - WAActionPhaseContinuation >> handleRequest - WAActionPhaseContinuation >> runCallbacks - PRPierFrame >> update - PRContentsWidget >> onChangeContext: - PRContentsWidget >> onAnswerCommand: This path is most probably not the same in Seaside 2.8; I can double check if necessary. The point is that my image works in Seaside 2.8 (that's basically the one I had during the last BlockParty in Paris). Let me then ask my question differently: Is the *restriction" introduced in *GRPharoPlatform >> seasideCallbackMarker* is something *unnegotiable* (for example, related to the design of partial executions in Seaside 3, or whatever other fundamental reason)? Or, it would be possible to change it so as to accommodate #call: s in the above frame (#runCallbacks)? Thank you in advance for your response, Regards, Reza

2 1

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release
by Reza RAZAVI 17 Apr '10

17 Apr '10

Hello Lukas, all, I've recently encountered an issue with the new implementation of WATask, and feel that I should report it now. It has already been shortly reported to the Pier mailing list (please see emails entitled *Contextual #call: issue*), but I've certainly not been explicit enough. So, let me first situate briefly the context, and then describe that issue. My apologies beforehand for the rather long post. During the past months, I've been implementing an on-line flow modeling and execution tool, which has been made possible specifically thanks to Seaside and Pier (and the Smalltalk Community in general). This tool is particularly useful when: - The control flow can only be known at runtime (with applications, for example, to support daily life activities), and - The control flow is subject to frequent changes in time and space whilst the web application is already deployed (for examples of application domains, please see [1]). Roughly speaking, this tool (framework) is composed of two sub-systems: - A web interface that complements Seaside and the Smalltalk browser in that it allows specifying on-line flows of Seaside components (equivalent to WATask >> go methods). - An execution engine (interpreter) that executes those flow models. Additionally, that execution engine is fully integrated in Pier's interpretation cycle. Specifically, each flow model behaves as a new (isQuick) Command, and its execution is triggered by PRContentsWidget. Since, flow models may reflect arbitrary interactions between Seaside components, including iterations and conditionals, once the execution of a flow model is triggered, it may involve a (large) number of #call: to other Seaside components (as well as other types of components). This has been perfectly functioning in Seaside 2.8, and Pier 1. Now, with Seaside 3.0 and Pier2, I encounter an issue that I've unfortunately not yet had time to characterize enough, but it looks like that my way of calling Seaside components confuses its new method of handling callbacks (although it has been functioning with Seaside 2.8). Here is a case that happens repeatedly: 1) The current page renders an internal link to a (Pier) context that when activated triggers the execution of a flow model. This is comparable to the links that appear in Pier's toolbars, like Add, Edit, etc. 2) The user clicks on that link. The context is activated, the execution of the flow model is launched, which yields to a #call:. At this point, GRPharoPlatform >> seasideCallbackMarker raises its exception, which is catched by PRContentsWidget >> onAnswerCommand:, and rendered by Pier as the result of the execution. The execution stops there, although the flow model corresponds actually to the Sushi Store checkout process, as implemented by Seaside, and documented here [2]. So, the user was rather expecting to go through the Fill Cart / Confirm Content iteration. 3) The user clicks on an item in the main menu (on the top), selected arbitrarily (the behavior that follows does not depend on the menu item selected). At this point, Seaside/Pier activate the component that was #call:'ed at the begging of the execution of the flow model in step (2), and was supposed to be activated during that stage (in place of that error message). This activated component is actually the first in that Sushi Store checkout process, namely *Fill cart*. Once launched in this way, then the execution flows smoothly to the end. What would be the best way to fix this? Regards, Reza Razavi [1] <http://adaptiveobjectmodel.com/>http://adaptiveobjectmodel.com/ [2] Seaside A Multiple Control Flow Web Application Framework Stéphane Ducasse, Adrian Lienhard, Lukas Renggli At 09:41 15/04/2010, Lukas Renggli wrote: >We should get a release candidate of Seaside 3 out ASAP. There is a >significant amount of adoption, no critical bug reports and I don't >see any obvious issues that would block a release. > >I've retagged some issues from 3.0 to 3.1 that I think are not >critical. There are two issues that I think require some attention >(correct me if not): > > http://code.google.com/p/seaside/issues/list?q=milestone=3.0 > >Anything else that cannot be delayed until 3.1? 3.2? > >Also I think we should go a little faster and give up on this crazy >alpha1..n,beta1..n versioning scheme. It does not scale for us. Let's >release 3.0 now, release 3.1 for ESUG, and 3.2 by the end of the year. >Each increment with its own small set of valuable improvements and >bug-fixes. Let's not strife for the "perfect" release. > >Lukas > >-- >Lukas Renggli >www.lukas-renggli.ch >_______________________________________________ >seaside-dev mailing list >seaside-dev(a)lists.squeakfoundation.org >http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2 3

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release
by Reza RAZAVI 17 Apr '10

17 Apr '10

At 21:50 15/04/2010, you wrote: >What are the exact steps that I need to follow to reproduce >a fresh Pier image and WAFlowConvenienceFunctionalTest? Hi Lukas, all, I started looking at this and had some observations that I'd like to share with you hereafter. I did the followings: 1) Picked http://www.seaside.st/distributions/Seaside-3.0a5.app.zip 2) Loaded from http://source.lukas-renggli.ch/pier2addons - Pier-Blog-lr.138 - Pier-Setup-lr.83 3) Executed *PRDistribution new register* 4) Modified *aCommand execute* in *PRContentsWidget >> onAnswerCommand:* as follows: [(aCommand isKindOf: PRAddCommand) ifTrue: [ self call: WAFlowConvenienceFunctionalTest new. self context command answer: self context] ifFalse: [aCommand execute] ] on: Error do: [ :err | ^ self component errors add: err ]. 5) Pointed my browser to http://localhost:8080/pier/ 6) Logged-in as admin/pier 7) Pressed the *Add* link in the Commands toolbar (to add a child to /). 8) Pressed the *Add* button in the dialog. At this point, Seaside / Pier render *What's your favorite Cheese?* etc., which is what I was expecting. The Component of PRContentsWidget, which is an MAContainerComponent, delegates its rendering to the WAFlowConvenienceFunctionalTest instance, due to the #call:. Now, I followed visiting pages: 9) Pressed the *About* link. The default content is displayed. 10) Pressed to "Home* link. Then, WAFlowConvenienceFunctionalTest displays instead of the default content. 11) Refreshed the *Home* page using my browser (Chrome), WAFlowConvenienceFunctionalTest keeps displaying instead of the default content. Since I didn't use the back button in (10) & (11), I would personally expect to see the default content. Otherwise, how the user could get ride of that component, without executing it until it *answers*, or creating a new session? Does that make sense? Technically speaking, shouldn't those Delegations be released once the page is refreshed (at least in the case of Pier as a CMS)? BTW, this relates to the 3rd point in my previous email on this topic, copied below, although not exactly the same: 3) The user clicks on an item in the main menu (on the top), selected arbitrarily (the behavior that follows does not depend on the menu item selected). At this point, Seaside/Pier activate the component that was #call:'ed at the begging of the execution of the flow model in step (2), and was supposed to be activated during that stage (in place of that error message). This activated component is actually the first in that Sushi Store checkout process, namely *Fill cart*. Once launched in this way, then the execution flows smoothly to the end. It looks like the Delegation has been created, in spite of the *GRPharoPlatform >> seasideCallbackMarker* error message reported in the 2nd point of that email. I've some intuitions about the cause of this error. I'll share it in a post that will follow. Regards, Reza

1 0

Re: [Seaside-dev] Remaining Issues for Seaside 3.0 release
by Reza RAZAVI 15 Apr '10

15 Apr '10

Hi Lukas, Many thanks for your consideration and feedback! At 21:50 15/04/2010, Lukas Renggli wrote: >I cannot reproduce the problem by embedding >WAFlowConvenienceFunctionalTest into Pier. It works for me. I understand, it shouldn't be easy to reproduce since I'm probably using that mechanisms in somehow unconventional/unexpected way, w,r,t the design of partial continuations in Seaside 3. >What are >the exact steps that I need to follow to reproduce a fresh Pier image >and WAFlowConvenienceFunctionalTest? I've to work on this, and also double check my code. I'll be back on this topic asap, probably during this week-end. >Furthermore can you verify that in your installation the configuration >of the Pier system uses the settings displayed in the attached >screenshot? Yes, that's exactly that. Later, Regards, Reza

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev April 2010