seaside-dev June 2010

seaside-dev@lists.squeakfoundation.org

7 participants
12 discussions

ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for a bit of review
by Dale Henrichs 24 Jun '10

24 Jun '10

This version of Seaside30 covers the latest mcz files (as of 6/21/2010 14:32), has been ported to GLASS 1.0-beta.8, includes the dependency of Seaside-Development on Seaside-Environment (so that WAWalkbackErrorHandler gets installed as #exceptionHandler), includes the Base group definition and includes the Seaside-Welcome page. I would like to release 3.0.0-alpha5.15 for the GLASS users relatively soon, but I thought I'd get some feedback on what's included before releasing it... I'd like to get a bit of feedback on: - the definition of the 'Base' group - whether a 'Development' group should/could be defined - whether other groupings might be needed - on the inclusion of Seaside-Welcome. Looking at a load of the 'Base' group these are the packages that are loaded: linear load : linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] load : ConfigurationOfGrease linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] linear load : 1.0-alpha9.3 [ConfigurationOfGrease] load : Grease-Core-pmm.42 load : Grease-Pharo-Core-pmm.23 load : Seaside-Core-pmm.648 load : Seaside-Pharo-Core-pmm.9 load : Seaside-Component-lr.82 load : Seaside-Canvas-pmm.95 load : Seaside-Session-jf.132 load : Seaside-RenderLoop-lr.72 load : Seaside-Tools-Core-lr.17 load : Seaside-Widgets-obi.18 load : Seaside-Environment-lr.69 load : Seaside-Pharo-Canvas-lr.3 load : Seaside-Pharo-Environment-lr.6 this matches the list that Julian (or was it me?) proposed, so I think we are in good shape:) I have not added a 'Development' group, because I'm not sure what would need to be included beyond Seaside-Development (and it's dependents). If there another couple of packages that you would consider development packages (like including Slime?) then a 'Development' group would be called for. As for other groups I can imagine a 'Flow' group would be useful if a package beyond Seaside-Flow (and it's dependents) would be required... Finally, when you load the Seaside-Welcome page using this expression: (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Base' 'Seaside-Adaptors-Comanche' 'Seaside-Welcome' ). quite a bit gets loaded, because of the inclusion of the Task example (WAFlowConvenienceFunctionalTest in Seaside-Tests-Flow)... here's the list of mcz files: linear load : linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] load : ConfigurationOfKomHttpServer linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] load : ConfigurationOfGrease linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] load : ConfigurationOfGrease linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30] linear load : 1.0-alpha9.3 [ConfigurationOfGrease] load : Grease-Core-pmm.42 load : Grease-Pharo-Core-pmm.23 linear load : 1.0-alpha9.3 [ConfigurationOfGrease] load : Grease-Tests-Core-DaleHenrichs.58 load : Grease-Tests-Pharo-Core-jok.7 load : Seaside-Core-pmm.648 load : Seaside-Pharo-Core-pmm.9 load : Seaside-Component-lr.82 load : Seaside-Canvas-pmm.95 load : Javascript-Core-DaleHenrichs.87 load : Javascript-Pharo-Core-DaleHenrichs.9 load : JQuery-Core-lr.106 load : JQuery-UI-obi.58 load : Seaside-Session-jf.132 load : Seaside-RenderLoop-lr.72 load : Seaside-Tools-Core-lr.17 load : Seaside-Flow-lr.21 load : Seaside-Examples-jok.18 load : Seaside-Widgets-obi.18 load : Seaside-Tools-Web-obi.89 load : Seaside-Environment-lr.69 load : Seaside-Development-jf.134 load : Seaside-Tests-Core-pmm.195 load : Seaside-Tests-Pharo-Core-pmm.12 load : Seaside-Tests-Component-lr.29 load : Seaside-Tests-Canvas-pmm.49 load : Seaside-Tests-Functional-obi.121 load : Seaside-Tests-Flow-YM.27 load : Seaside-Welcome-obi.12 load : Seaside-Tests-Session-pmm.39 load : Seaside-Tests-RenderLoop-lr.11 load : Seaside-Tests-Environment-lr.23 linear load : 1.0.2 [ConfigurationOfKomHttpServer] load : DynamicBindings-lr.13 load : KomServices-lr.20 load : KomHttpServer-pmm.53 load : Seaside-Pharo-Canvas-lr.3 load : Seaside-Pharo-Environment-lr.6 load : Seaside-Tests-Pharo-Functional-lr.12 load : Seaside-Pharo-Tools-Web-lr.21 load : Seaside-Pharo-Continuation-lr.5 load : Seaside-Tests-Pharo-Continuation-lr.7 load : Seaside-Pharo-Flow-lr.5 load : Seaside-Pharo-Development-lr.42 load : Seaside-Adaptors-Comanche-pmm.59 Let me know if you'd like to see changes ... I can always release another version if you want to add groups or make other tweaks... Dale

3 23

A couple of suggestions/observations ... related to using the 'Base'
by Dale Henrichs 24 Jun '10

24 Jun '10

After sending the earlier email discussing the 'Base' group for ConfigurationOfSeaside30, I started work finishing up the GemStone port of Magritte2... Given that we have a 'Base' group for Seaside, I thought that it would be a good idea to see just how much of Seaside Magritte-Seaside itself required starting with loading just the 'Base' seaside group. One thing I found out was that Magritte expects Seaside-HTML5 to be present... so that was easy enough to deal with... Another thing that popped up is that there was no default dispatcher (by default:) which is not surprising once you think about it, but loading just Magritte-Seaside on top of the 'Base' it would be nice if there were a way to register a default 'default dispatcher' ... something like what happens with exception handlers so that if nothing else come ins, the lone registered component somehow becomes the default ... The Magritte-Seaside component is actually in Magritte-Seaside-Examples, so perhaps the examples should be split out for Magritte2 so that they can be loaded separately and then it would make more sense to be registering a default 'default dispatcher' directly.. I like the notion of having Magritte-Seaside depend upon the 'Base' from Seaside ... Basically a developer would then do something like the following for loading into a production image: (ConfigurationOfMagritte2 project version: '2.0.5') load: 'Magritte-Seaside'. (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Seaside-Adaptors-FastCGI' ). and then do the following in a development image: (ConfigurationOfMagritte2 project version: '2.0.5') load: 'Magritte-Seaside'. (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Seaside-Adaptors-FastCGI' 'Seaside-Development'). ConfigurationOfMagritte could be replaced with any application that used Seaside and similarly load the minimal set of Seaside using explicit dependencies from within the configuration .. then the development pieces could be incrementally loaded in the development image... Fnally, for GemStone, I have implemented an ObjectLog viewer/editor component ... in production, it is convenient to have the object log viewer installed (using authentication), however, the object log viewer uses WAInspector which is currently packaged with Development which installs (and initializes) a bunch of other things I don't want in production ... it would be nice if WAInspector were refactored to be usable in a production environment (no tool bar inherited from WATool) ... this would involve moving WAInspector to Seaside-Tools-Core and then implementing a development version that 'mixed in' the toolbar css and friends... In looking through the other development components I don't see any other components that would be as useful to have in a production installation... Dale

2 5

please delete Seaside-GemStone-Adaptors-Swazoo-dkh.1.mcz from http://www.squeaksource.com/Seaside30
by Dale Henrichs 24 Jun '10

24 Jun '10

That was inadvertantly committed there a while back .. there's a copy of the mcz file in http://seaside.gemstone.com/ss/Seaside30 (the primary repository) Thanks, Dale

2 1

Generated images always converted to gif
by Stuart Herring 17 Jun '10

17 Jun '10

Hi All, I found a problem in Seaside3.0 when trying to render a generated image as a jpeg via WAImageTag>>document:mimeType: Because of the way WADocumentHandler>>document:mimeType:fileName and Form>>seasideMimeDocument are implemented, it results in the image always being converted to a gif. See: http://code.google.com/p/seaside/issues/detail?id=577 for more details and proposed fix. Regards, Stuart

2 3

Re: [Seaside Commits] Seaside 3.0: Seaside-Tools-Web-obi.84.mcz
by Julian Fitzell 14 Jun '10

14 Jun '10

I don't think that can be right... #url will return a full URL if serverName, etc. are set... why not use WADispatcher>>handlerAt: combined with #defaultName to get the default dispatcher and compare for identity? I'm also a bit confused by the use of #defaultDispatcher here... don't we need to be checking the default name of whatever dispatcher we're currently viewing? Also, there's no EntryPoint class anymore so the parameter name is a bit confusing. :) Julian On Sat, Jun 12, 2010 at 8:36 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Gerhard Obermann uploaded a new version of Seaside-Tools-Web to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Seaside-Tools-Web-obi.84.mcz > > ==================== Summary ==================== > > Name: Seaside-Tools-Web-obi.84 > Author: obi > Time: 12 June 2010, 7:40:06 pm > UUID: b06710cd-7b0a-4c4f-8c1e-f2243f40df05 > Ancestors: Seaside-Tools-Web-obi.83 > > - compare urls instead of strings to get the default application > > =============== Diff against Seaside-Tools-Web-obi.83 =============== > > Item was changed: > ----- Method: WAConfigurationBrowser>>renderRowName:named:on: (in category 'rendering-rows') ----- > renderRowName: anEntryPoint named: aString on: html > html anchor > class: 'selected' if: anEntryPoint = selection; > callback: [ self configure: anEntryPoint ]; > with: [ > anEntryPoint isDispatcher > ifTrue: [ html text: aString , '/' ] > ifFalse: [ > html text: aString. > + (WAUrl absolute: self defaultDispatcher defaultName) = anEntryPoint url > - self defaultDispatcher defaultName = anEntryPoint url greaseString > ifTrue: [ html span > title: 'Default application'; > with: ' (*)'] ] ]! > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits >

3 7

metacello packaging
by Julian Fitzell 14 Jun '10

14 Jun '10

Dale, What's the status of the metacello refactoring you were looking at? I'm getting a lot of pressure to release an RC; I was hoping to release it in conjunction with an metacello config but am just wondering whether to go ahead without that. Julian

3 6

Re: [Seaside Commits] Seaside 3.0: Seaside-Welcome-lr.7.mcz
by Julian Fitzell 14 Jun '10

14 Jun '10

Hey Lukas, So far, this version feels less welcoming to me. I'm not saying it can't work (it sounds like you intend to do more on it) but the layout currently feels colder and I find it "disorienting" somehow, maybe because the regions aren't well defined and all the links are sort of different and going "back" is different in each case. I don't get any sense of "where I am" and the layout doesn't tell me, at a quick glance, what I should click on first. And I have to scroll both horizontally and vertically. Unless you object, I'm inclined to include version 6 in the RC for now until this concept gets further developed... Julian On Sun, Jun 13, 2010 at 6:43 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Lukas Renggli uploaded a new version of Seaside-Welcome to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Seaside-Welcome-lr.7.mcz > > ==================== Summary ==================== > > Name: Seaside-Welcome-lr.7 > Author: lr > Time: 13 June 2010, 5:43:45 pm > UUID: 0c26b2d7-9e25-4f8f-9e5a-2bdbbc6405fc > Ancestors: Seaside-Welcome-jf.6 > > - trying to steamline and simplify the welcome screen (no examples for now)

3 6

WAResponseGenerator>>expiredKey
by Nick Ager 14 Jun '10

14 Jun '10

Hi, Selecting a different look using Pier's PRDesignChooserWidget causes an WAUnregisteredHandlerError exception to be raised. This occurs on the latest builds: http://hudson.lukas-renggli.ch/job/Pier%202/lastBuild/ The PRDesignChooserWidget registers 'pier' with the new structure in place then sends an #expiredKey response as: self requestContext responseGenerator expiredKey; respond The problem appears to be in a change to WAResponseGenerator>>expiredKey, which was introduced: --- Name: Seaside-Core-YM.639 Author: YM Time: 22 May 2010, 7:39:33 pm UUID: e24bae83-3671-4679-ac8d-9f21154c304e Ancestors: Seaside-Core-pmm.638 http://code.google.com/p/seaside/issues/detail?id=552 - Corrected WAResponseGenerator>>#expiredKey to always use the correct URL - Implemented WAPathConsumer>>#upToEnd ---- The exception is thrown in the line: url := self requestContext handler url. #handler returns a WASession which I presume wasn't expected when the code was written. Changing the code to: url := self requestContext request url stops the exception from being thrown, but doesn't result in a URL free from keys; not the desired effect. I found a handy Pier extension method WAUrl>>purgeSeasideFields.The rewritten WAResponseGenerator>>expiredKey then becomes: expiredKey "The session key has expired, redirect the request to the home directory preserving the path as well as possible." | url | self request isXmlHttpRequest ifTrue: [ ^ self forbidden ]. url := self requestContext request url. url addAllToPath: self requestContext consumer upToEnd. self request isGet ifTrue: [ url purgeSeasideFields]. self response redirectTo: url With the requirement that the WAUrl>>purgeSeasideFields is moved from Pier-Seaside-Mapping into Seaside-Core-HTTP. Thoughts? Nick

2 2

hudson failure?
by Julian Fitzell 14 Jun '10

14 Jun '10

Lukas, Is this a problem with the Hudson environment or a problem in Seaside? http://hudson.lukas-renggli.ch/job/Seaside%203.0/215/console Julian

3 2

pharo 1.0 or 1.1?
by Julian Fitzell 14 Jun '10

14 Jun '10

Anybody have opinions on what version I should use for the one-click? Julian

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev June 2010