seaside-dev December 2010

seaside-dev@lists.squeakfoundation.org

8 participants
10 discussions

Re: [Seaside Commits] Seaside 3.0: Seaside-Core-jf.682.mcz
by Julian Fitzell 09 Jan '11

09 Jan '11

Philippe, I'm not clear why we need an empty WANullReapingStrategyConfiguration... other strategies seem to just use a WAUserConfiguration. Is that causing problems somewhere? It also doesn't look like WANullReapingStrategy>>#reap is technically needed - the method is never called by the superclass (though perhaps it is better to have it for clarity anyway...) Julian On Wed, Dec 29, 2010 at 12:00 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > Julian Fitzell uploaded a new version of Seaside-Core to project Seaside 3.0: > http://www.squeaksource.com/Seaside30/Seaside-Core-jf.682.mcz > > ==================== Summary ==================== > > Name: Seaside-Core-jf.682 > Author: jf > Time: 29 December 2010, 10:59:23 am > UUID: 0d531869-000f-4adb-85e2-424e8386d435 > Ancestors: Seaside-Core-pmm.681 > > Rename WANoReapingStrategy* to WANullReapingStrategy* > > > _______________________________________________ > commits mailing list > To unsubscribe, email commits-leave(a)lists.seaside.st > http://lists.seaside.st/listinfo/commits >

3 9

My first contribution
by Tony Fleig 01 Jan '11

01 Jan '11

I have made some changes in my local environment to Phato's MailMessage and Seaside's WAEmailMessage to support creation of multi-part MIME messages (e.g. HTML and plaintext). I would like to contribute these changes, but I'm not sure how to proceed because the Seaside changes are dependent on the Pharo changes. Should I submit all the changes to Seaside and include the Pharo changes as Seaside extensions to Pharo or submit the changes separately to Pharo and Seaside? And of course my changes are for Pharo only and therefore the other Seaside platforms would not be supported. Do I need to make sure this works on all platforms before submitting? Cheers, TF

3 2

Pier/Magritte Dynamic Descriptions
by Joel Kitching 31 Dec '10

31 Dec '10

Recently I was trying to puzzle out how to provide some descriptions on some objects that changed based on other descriptions. A concrete example of this is: a Flickr photo, with two descriptions: - photo ID - which JPG size to use The second description depends on the first -- one can't retrieve the available sizes to choose from without first getting the photo ID. So I did a bit of Googling around, and came across an On Smalltalk [1] article, where it mentioned something about this: > Generally speaking you'll keep these descriptions on the class side of > your domain object. On occasion, you'll want some property of the > description to be dynamic and depend on the actual value of an instance > side value, so you'll move the description to the instance side. > Strictly speaking, it doesn't matter where you put them, sometimes > you'll use them to build forms when you don't even have a domain object, > but this isn't the normal case. Then I did some further looking, and found some tutorial [2] that actually gives some information on doing this (without Pier). It seems like in general (based on this tutorial) you implement #descriptionEdit, and then grab that when handling the editing function in whatever UI you choose. That said, I've been struggling to figure out how I can do this with a PRWidget in Pier. There seems to be some way of doing it with a PRStructure, as PRFile provides editing capabilities on a text-based file by overriding #editDescription. But I'm not sure how it would work with a PRWidget, or if it is even possible. Basically, I would envision it as follows in the UI, continuing with the Flickr photo example: - Create a new photo widget - Edit the photo widget -- the size property either does not show or is not populated - Input a photo ID - Either submit the form, or have something realize it has what it needs to populate the next field and transmit the data without a page refresh - Select the photo size, and submit Is there any way of accomplishing this with the existing support for Magritte in Pier? Or is this something that could be (or should be) hacked into PRWidget? Or am I going about this in a completely wrong way? Any advice would be much appreciated. Thanks, Joel [1] http://onsmalltalk.com/using-magritte-with-seaside [2] http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?chapter=10#part4

2 1

[ANN] Seaside 3.0.3 release
by Philippe Marschall 18 Dec '10

18 Dec '10

We are pleased to announce the release of Seaside 3.0.3. This is a bugfix release for Seaside 3.0. We recommend all users of Seaside 3.0 to update. A changelog is available at [1] Special thanks to Dale for making this possible. [1] http://code.google.com/p/seaside/wiki/Seaside303Changelog The Seaside Team

1 0

Instal of Seaside 3.0.3 fails on Pharo
by scott lewis 18 Dec '10

18 Dec '10

Just me, or does the standard Gofer install of seaside 3.0.3 fail on a new Pharo image? It gets stuck on: scanTokens: aString "compatibility" ^ Array with: (self scan: aString readStream) aString is nil

2 1

Seaside 3.0.3....
by Dale Henrichs 16 Dec '10

16 Dec '10

Just a reminder that I'm stuck on Step 6 of the release process. I have the image/changes and one click distribution artifacts for 3.0.3, but I don't have access to the seaside.st server (nor a login to the seaside.st website)..... Dale

2 1

MakeRelease process
by Dale Henrichs 14 Dec '10

14 Dec '10

It seems to me that the hudson server is already building the needed release artifacts as well as running the tests ... so building the release artifacts manually seems redundant and error prone. The only fly in the ointment is that the hudson server (presumably) loads the latest code whenever it does it's build/test cycle. Which means that 5 minutes after the decision to make a release someone could check in a new package that wasn't intended to be part of the release. If the hudson server built a set of artifacts based on the Metacello configuration for Seaside30, then we'd have a stable definition for the product artifacts...then the process would be something like: 1. Update version numbers... 2. Load all latest code.... 3. Update the Metacello config... 3.5 wait 24 hours 3.6 verify that hudson tests pass 4. (should be done by hudson server?) 5. snap off a new change log 6. copy hudson artifacts to website... etc... Dale

1 1

Grease 1.0.3 and Seaside 3.03 are poised for release.
by Dale Henrichs 14 Dec '10

14 Dec '10

Seaside3.0.3 has been loaded and tested on Pharo1.0, Squeak4.1, Pharo1.1.1, and GLASS 1.0-beta.8.4...all tests run Green and the Metacello configurations have been marked as released. In going through the steps on the Make Release page: http://code.google.com/p/seaside/wiki/MakeRelease?ts=1291839439&updated=Mak… I discovered a handfull of issues which I am detailing here: Step 2.2: This needs to be automated, there are way too many combinations to test manually especially if you are interested in releasing often (tell me how many times has the Swazoo adaptor been tested with koi8-r encoding (and would I be able to tell if there was a bug)?) Step 4: I ran the doit ... code executed but I got no feedback good or bad from running #graphFunctionalDependencies:tests: Step 5: I click on the link and I get a csv file ... what is supposed to be done with it? Is this step subsumed by the ChangeLog page? Step 6: Not sure where the image/changes file is supposed to come from and I'm pretty sure I don't have permissions to modify any of the links Step 7: No access to twitter... Step 8: Can't update until Step 6 is completed. So in the end, I think we're awfully dang close to releasing 3.0.3 ... the code is ready, but the release artifacts (like the one-click image and website updates haven't been done...). Dale

2 5

3.0.2.1 vs 3.0.3
by Philippe Marschall 08 Dec '10

08 Dec '10

Hi Given the amount of fixes we already have [1] and Dale is going to do a release anyway I'd rather have it made official named 3.0.3 instead of 3.0.2.1. These days making a release it pretty straight forward [2] thanks to the Hudson of Lukas. The biggest thing is the Metacello config which won't be a problem for you. And since you're paid to do this I'd say you do the release Dale ;-) [1] http://code.google.com/p/seaside/wiki/Seaside303Changelog [2] http://code.google.com/p/seaside/wiki/MakeRelease Cheers Philippe

4 9

please delete package
by Dale Henrichs 07 Dec '10

07 Dec '10

Please delete Seaside-Core.gemstone-DaleHenrichs.669.mcz from the Seaside30 repository on SqueakSource..inadvertantly committed there... Thanks, Dale

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

seaside-dev December 2010