smallwiki

smallwiki@list.inf.unibe.ch

2312 discussions

by Julian Fitzell

On Sun, Jun 27, 2010 at 6:54 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Once you've loaded one of these configs, there will be no development tools > nor any adaptors so at a minimum you'll need to load one of the following > depending upon which adaptor you want to use: > > "All platforms" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Swazoo'). > "Squeak and Pharo" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-Comanche'). > "GemStone" > (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') > load: #('Seaside-Adaptors-FastCGI'). This, of course, is why package management systems like RPM and Deb end up having "provides". This would allow Seaside-Base to require "http-adaptor" or something and each of those packages to provide "http-adaptor". The package manager can then look for possibilities and prompt if it finds more than one. Not saying you need to go that route, but it's probably the "traditional" solution. Julian

14 years, 6 months

New structure for Seaside30, Magritte2, and Pier2 Metacello configurations

by Dale Henrichs

I am looking for a little feedback on the changes that I have made to the latest configurations of Seaside30, Magritte2, and Pier2. I have new versions for each of these configurations queued up for release (#development blessing), but before releasing them I'd like to hear if the changes I've made will cause trouble for folks using Magritte2 and/or Pier2 in their applications. In the past, when you referenced Seaside30 from a configuration, the entire Seaside3.0 release would be loaded, including development tools, examples, both adaptors (on Squeak/Pharo and GemStone)...basically the whole kitchen sink. With the 3.0.0-alpha5.15 release I've defined several groups for Seaside3.0 (with feedback from the Seaside devs:): Base, Base Tests, Development and Development Tests. I will also add a One-click group to shdow the one-click release. Without going into too much detail, the Base group defines the set of packages that are needed for a production release, while the Development group defines the set of packages that are useful in development (on top of the Base). To see how these new groups work out, I have created new versions of the configurations for Magritte2 and Pier2 that reference the Base group (plus any other packages that were needed) instead of bringing in the entire Seaside3.0 release...This is the big change. After loading the Magritte2 or Pier2 configuration you will need to load from the Seaside30 configuration any and all packages that you may need for your own application. I haven't released the changes yet, but if you are curious or concerned you can try out the releases ahead of time ... depending upon feedback I may go with a different scheme. In a fresh image, you can see what will be loaded for production by executing one or more of the following expressions (note you need to get the latest version of each of the configs from the SqueakSource MetacelloRepository...oh and for best results use Metacello 1.0-beta.27.1): (ConfigurationOfMagritte2 project version: '2.0.5') load. (ConfigurationOfPier2 project version: '2.0.6') load. (ConfigurationOfPierAddOns2 project version: '2.0.6') load. Once you've loaded one of these configs, there will be no development tools nor any adaptors so at a minimum you'll need to load one of the following depending upon which adaptor you want to use: "All platforms" (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Seaside-Adaptors-Swazoo'). "Squeak and Pharo" (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Seaside-Adaptors-Comanche'). "GemStone" (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Seaside-Adaptors-FastCGI'). If you want to load in the Seaside development environment then you would evaluate the following expression: (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15') load: #('Development'). So at this point you can see the direction I'm going with this ... the Magritte2 and Pier2 configurations are currently aimed at loading the bare minimum needed for functionality from Seaside3.0 for Magritte2 and Pier2 with the idea that you'd load the additional functionality that you want by dealing directly with Seaside30 configuration (like loading adaptors and development)... Pier2 already depends upon the following javascript packages: 'Javascript-Core' 'Prototype-Core' 'Scriptaculous-Core' 'JQuery-UI' but if you're currently using Magritte2 and javascript, then you'll need to explicitly load the javascript package(s) that you are using. There are other ways that the configs could be structured. This approach minimizes the coupling between the Seaside3.0 and Magritte2/Pier2 configurations, which I think is a good thing. I've taken the bare minimum step: loading what is required... it would be reasonable to add 'Dev' groups to both Magritte2 and Pier2 that would bring in Seaside30 dev support on the other hand, I don't think it is reasonable to add support for loading the various Adaptors to Magritte2 and Pier2, so if you're going to have to deal with the Seaside30 config directly anyway why bother with adding dev groups ... Anyway this is what _I_ think and I am interested in what you folks think... For GemStone folks ... the answer is yes, Magritte2 and Pier2 have been ported to GemStone/S 64 2.4 finally:). If you've been working with Seaside3.0 already, you can load the Magritte2/Pier2/PierAddOns2 configs into a fresh 1.0-beta.8....otherwise I'll ask you to wait until I announcement. Dale

14 years, 6 months

[ANN] ESUG Awards 2010

by Luc Fabresse

Dear Smalltalkers, You are invited to submit your nice Smalltalk based software to the 7th ESUG Innovation Technology Awards. The top 3 teams with the most innovative software will receive, respectively, 500 Euros, 300 Euros and 200 Euros during an awards ceremony at the 18th International Smalltalk Joint Conference 2010 in Barcelona, Spain. No constraints are put on the software except that it should be Smalltalk-based or Smalltalk-related and all flavours of Smalltalk are accepted. More details on the web (submission process, ...): http://www.esug.org/Conferences/2010/Innovation+Technology+Awards Results of the 2009 edition: http://www.esug.org/Conferences/2009/Innovation+Technology+Awards/Winners+a…

14 years, 6 months

Hey,

by isaiah perumalla

Hi, How are you? I have good news for you. Last week, I order one Lenovo Apple iPad Tablet (64GB, Wifi + 3G) from this website: www.Mrcmall.com. I've received the item today. It's amazing! The item is original, brand new and has high quality, but it's much cheaper. I'm pleased to share this good news with you! I believe you will find what you want there and have an good experience on shopping from them. Best regards! _________________________________________________________________ Need a new place to live? Find it on Domain.com.au http://clk.atdmt.com/NMN/go/157631292/direct/01/

14 years, 6 months

JQFormExampleTest>>testExampleClass fails

by Dale Henrichs

I am porting/testing the Pier-JQuery addOn (from the Pier2 addons) to GemStone and it requires JQueryWidgetBox, which I have also loaded into GemStone which is how I have discovered that the JQFormExampleTest>>testExampleClass test fails... The expected javascript is: $(this).example("Example Text",{className:"fancy"}) but the following is being output: $(this).example("Example Text",{"className":"fancy"}) I'm not familiar enough with javascript to know whether the expected javascript is correct or whether the actual output is correct... The test is using JQueryInstance to generate the javascript and it looks like the JQueryInstance is testing a similar pattern of javascript so I _assume_ that the expected javascript is wrong, but I wanted to double check before changing the test... Dale

14 years, 6 months

Pier-Twitter (for Pier2) should use Grease utf8 decode: instead of TextConverter?

by Dale Henrichs

I'm porting Pier2 and friends to GemStone and Pier-Twitter is using TextConverter for decoding UTF8...since Grease is a prereq anyway, shouldn't Pier-Twitter (for Pier2) use GRcodec? Dale

14 years, 6 months

several uses of #ifNotNil: in PierSecurity (Pier2)

by Dale Henrichs

I'm porting to Pier2 to GemStone and ran into several places where #ifNotNil: is being used ... what is the accepted replacement for #ifNotNil: ... I can clean these up as part of my port. Dale

14 years, 6 months

MAReportComponent>>renderTableCaptionOn: sends #caption ... #caption not implemented

by Dale Henrichs

Not sure where to report Magritte bugs.... This is in Magritte-Seaside-lr.335 ... #caption is sent to a description, but I haven't found any implementors ... is this a bug waiting to happen or is magic involved:) Dale

14 years, 6 months

Auto login page for pier...

by Lawson English

Is there an option for a page similar to this for Pier? https://www.iam.unibe.ch/mailman/listinfo/smallwiki Suggestions on how to make my own, if there isn't? Thanks. Lawson

14 years, 6 months

WAResponseGenerator>>expiredKey

by Nick Ager

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

14 years, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki