seaside-dev September 2009

seaside-dev@lists.squeakfoundation.org

24 participants
44 discussions

Re: [Seaside Commits] Seaside 3.0: Grease-Core-jf.1.mcz
by Julian Fitzell 02 Oct '09

02 Oct '09

Sorry everyone, this is going to be a doozy to load, I know. This will basically be it for 3.0a5 - the functional tests turned up one bug I have to fix and then I'll try to get a profile up on the builder to make loading this easier for everyone else. Julian On Wed, Sep 30, 2009 at 10:47 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Julian Fitzell uploaded a new version of Grease-Core to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Grease-Core-jf.1.mcz > > ==================== Summary ==================== > > Name: Grease-Core-jf.1 > Author: jf > Time: 30 September 2009, 10:47:12 pm > UUID: 8702f9cb-4c9f-49fe-9b8f-ed45cd2d444a > Ancestors: > > Rename Seaside-Platform to Grease in order to help make clear that it is not Seaside-specific and can be used by other projects as a compatibility layer. This was spawned by discussions when I started porting Magritte to VAST using the Platform layer.

5 7

Re: [Seaside Commits] Seaside 3.0: Seaside-Tools-Web-obi.18.mcz
by Julian Fitzell 29 Sep '09

29 Sep '09

Cool. I was just going to send you an email and ask if you thought your improvements were ready to be included in an alpha... I guess this means yes? Julian On Mon, Sep 28, 2009 at 11:28 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Gerhard Obermann uploaded a new version of Seaside-Tools-Web to project Seaside 3.0:

5 6

[ANN] Issue 476: Prototype updater's broken
by sebastian＠flowingconcept.com 29 Sep '09

29 Sep '09

Hi guys, http://code.google.com/p/seaside/issues/detail?id=476 Seaside 3.0 screwed prototype updaters ideas? sebastian

3 5

Is Seaside-Core-obi.571 still needed?
by Lukas Renggli 29 Sep '09

29 Sep '09

Probably that can be removed from the repository? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

2 7

Re: [Seaside Commits] Seaside 3.0: Seaside-Core-obi.571.mcz
by Julian Fitzell 27 Sep '09

27 Sep '09

I wonder if this might be better as a class extension from the tools package? The knowledge of whether each item is inherited and so on is really only of interest to the tools... Julian On Sat, Sep 26, 2009 at 7:51 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Gerhard Obermann uploaded a new version of Seaside-Core to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Seaside-Core-obi.571.mcz > > ==================== Summary ==================== > > Name: Seaside-Core-obi.571 > Author: obi > Time: 26 September 2009, 7:52:30 pm > UUID: 8d4e1fe3-afa1-7840-80ef-083cc1af5b63 > Ancestors: Seaside-Core-jf.570 > > - add convenience method to WAUserConfiguration > > =============== Diff against Seaside-Core-jf.570 =============== > > Item was added: > + ----- Method: WAUserConfiguration>>currentCollectionAt: (in category 'values') ----- > + currentCollectionAt: key > + "get the currently defined values with infos for collection attributes" > + > + | expression attributeCollection | > + expression := self expressionAt: key ifAbsent: []. > + expression isNil > + ifTrue: [attributeCollection := (self at: key) collect: [:each | #inherited -> each ] ] > + ifFalse: [ > + (expression isKindOf: WAValueExpression) > + ifTrue: [attributeCollection := (expression value collect: [:each | #self -> each ]) asOrderedCollection] > + ifFalse: [attributeCollection := (expression additions collect: [:each | #add -> each]) asOrderedCollection. > + attributeCollection addAll: (expression additions collect: [:each | #remove -> each ]). > + (self at: key) > + do: [:each | > + (attributeCollection detect: [:assoc | assoc value = each] ifNone: []) isNil > + ifTrue: [attributeCollection add: #inherited -> each ] ] ] ]. > + ^attributeCollection! > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits >

2 2

Config tool prototype
by Gerhard Obermann 25 Sep '09

25 Sep '09

Hi! I have uploaded a prototype for a new hopefully improved config tool. If it will be finished it should address some open issues. A lot of feedback is welcome! see Name: Seaside-Tools-Web-obi.16 Author: obi Time: 21 September 2009, 10:35:48 pm UUID: 7388dc4b-8b89-7944-8728-a6d99638979a Ancestors: Seaside-Tools-Web-lr.15 - prototype for new configuration tool - should address some open issues if it will be finished - no changes on current editors at the moment - to test it change the root class of /config to WAConfigurationTool - still work in progress, css is inline, no refactoring,... Gerhard

4 9

Problem with JQSliderFunctionalTest
by GallegO 25 Sep '09

25 Sep '09

Hi! I have encountered the problem with the 2.9.a-4 ported to Dolphin. In Pharo the problem is hidden by the fact that '[object Object]' asNumber in Pharo answers 0 while in Dolphin raises an Exception. halting the callback for the slider value on the renderContentOn: of the test shows the problem. I'm apologize if this was resolved or reported previously. Someone that can give me a link to a seaside-dev find list page? Cheers Sebastian

3 7

Debugging in Seaside 3.0 (issue 340)
by Michael Lucas-Smith 23 Sep '09

23 Sep '09

Hi All, I'd like to kick off a (hopefully) short discussion on the direction of walkbacks and debugging with Seaside 3.0. There is an open issue for debugging and walkbacks, issue 340 ( http://code.google.com/p/seaside/issues/detail?id=340 ) which points out that the new way exception handling works and continuations work basically means showing a walkback, let alone debugging, is pretty much impossible in the way it was done in Seaside 2.8. You cannot render during an action, so any walkback during an action cannot be reported to the user without great difficulty. You can render during the render phase, but this often leads to a mess. Julian and I had a chat at ESUG about a potential solution to debugging and walkbacks in Seaside 3.0. Specifically the debugging - instead of trying to provide a debugging solution in the web browser, we let the development environment handle it as per normal. This means you'll get a debugger pop up in the GUI. It means that in production, instead of a walkback, users get an Internal Server Error of some kind. So how do we debug then? We have a separate Seaside request showing a list of debuggable processes, which you can refresh (and probably should refresh itself either via comet or polling) which you can click on to see a walkback, terminate, debug, etc. The question was posed: could this be done and could it be portable? Tamara Kogan has twisted the WebVelocity web debugger about until it is demonstrable, so here is the video: http://dl.getdropbox.com/u/20291/Cincom%20Smalltalk/Seaside-20090918-Debugg… The bad news: Every Smalltalk I looked at handles how the debugger is opened and how you debug a process completely differently. So while the technique is something that can be shared around the smalltalks, the code itself pretty much can't be. Recommendations: 1) An official "technique" could be published somewhere, on the seaside wiki perhaps, on how to implement debugging in Seaside for each implementation. 2) The WAExceptionHandler* classes can be removed to dissuade people from expecting a way to do this reasonably. What do people think about this? Cheers, Michael

6 12

Seaside 3.0b1 release schedule
by Michael Lucas-Smith 22 Sep '09

22 Sep '09

Hi All, VisualWorks 7.7 is approaching a release candidate period. I need to include Seaside 3.0 in to the builds soon, but I'd *really* like to say "VW 7.7 includes Seaside 3.0b1". I can only do that if b1 is released before I get frozen out of the 7.7 release process completely. The alternative is, I release something that's "not quite 3.0b1" which isn't ideal. I'm expecting the release candidates to begin in the next two weeks - is there any chance we'll have 3.0b1 ready before then? Cheers, Michael

10 24

Re: [Seaside-dev] Debugging in Seaside 3.0 (issue 340)
by Dale Henrichs 21 Sep '09

21 Sep '09

GemStone has both ui-less and ui-full modes for debugging, although the primary mode is ui-less ... a continuation is snapped off and the stack is stashed in the db (in the object log to be precise) as Michael mentioned before ... While I haven't implemented this yet, I've always imagined that there would be a process running that would clean out old entries in the Object log to keep it from growing without bounds ... When dealing with problems in the Seaside framework itself I resort to the standard technique of bringing up a a debugger in the ui... I'm riffing now, but presumably all platforms are able to suspend a process and I assume that all platforms have a way of bringing up a debugger on a suspended process ... so at a minimum I would think that a generic handler could be written that suspends the offensive process on an error, stashes the process in a platform-specific collection (via SeasidePlatform) and arranges for an error response to be returned .... the process could go into a queue, that is being polled or could cause a debugger to be opened, or could be logged into a log file and dropped on the floor ... Dale ----- "Michael Lucas-Smith" <mlucas-smith(a)cincom.com> wrote: | Philippe Marschall wrote: | > 2009/9/20, Michael Lucas-Smith <mlucas-smith(a)cincom.com>: | > | >> Lukas Renggli wrote: | >> | >>>>> Recommendations: | >>>>> 1) An official "technique" could be published somewhere, on | the | >>>>> seaside wiki perhaps, on how to implement debugging in Seaside | for each | >>>>> implementation. | >>>>> 2) The WAExceptionHandler* classes can be removed to | dissuade people | >>>>> from expecting a way to do this reasonably. | >>>>> | >>>>> What do people think about this? | >>>>> | >>>>> | >>>> I'm not particularly found of it. I don't like clever process | tricks. | >>>> | >>>> | >> Clever process tricks is what used to happen in Seaside 2.8. Now | it's | >> not doing anything clever at all. | >> In VisualWorks, when an exception is unhandled, a DebuggerService | is | >> created for the process and a DebuggerClient opens up on it. The | >> DebuggerService provides all the controls to manipulate the | process. | >> | > | > We don't have those fancy classes in Pharo. | > | Exactly the problem - there are different classes in GST, VA, Dolphin. | | This area of Smalltalk is anything but standard. | > | >> The two options are: let the GUI show the debugger, which is fine | for | >> most cases. Capture the service in a collection and let a web page | show | >> the debugger - which is the technique I described above. | >> | >>>> Additionally where do you store the processes and how do you | reap | >>>> them? | >>>> | >> They go in to a collection, you either reap them when you're done | >> debugging (resume or terminate) or you can terminate them before | you | >> debug. That's the same as the GUI is right now, which pops up a | debug | >> dialog asking you what you want to do with it. | >> | > | > Where is that collection? How do you remove stuff from this | > collection, do you have to debug every exception? How do you keep | this | > collection from filling up and preventing stuff from being | released? | > | The collection is on our WebDebuggerService right now. No you don't | have | to debug every exception. It's the same as having the dialog box pop | up | later, except in a list. Given that it's our list, we could even drop | | "old" services if people cared. Run away masses of exceptions are a | mess | in the GUI anyway. | >>>> Moreover not all platforms have a comet server. | >>>> | >> Right, as I said before, the debugging code is platform specific | anyway, | >> there's basically nothing reusable - except for the technique | itself. | >> Polling is just as acceptable, but there's no reasonable spot in | the | >> regular seaside to start polling or cometing for debug exceptions. | My | >> preference would be for seaside to not attempt to be a debugger at | all - | >> but for us to merely say "and this is how you can implement web | >> debugging if you want to" | >> | >>>> I'd rather just | >>>> open a debugger in the image, which is what your eventually going | to | >>>> do anyway. | >>>> | >>>> | >> Except if you don't have a GUI. | >> | > | > But we do. | > | VisualWorks, ObjectStudio, Pharo, Squeak, VisualAge, Dolphin all do - | | WebVelocity doesn't. | Is WV unique in this or are other projects interested in ui-less | development too? | | Anyway - we're saying the same thing. There is a technique to do web | debugging with Seaside that isn't intrusive and isn't required. | | I believe all we need to do for issue 340 is to remove the debugger | handlers? Julian? | | Michael | _______________________________________________ | seaside-dev mailing list | seaside-dev(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev September 2009