seaside November 2003

seaside@lists.squeakfoundation.org

35 participants
25 discussions

Background pattern
by Torsten.Bergmann＠phaidros.com 19 Nov '03

19 Nov '03

Hi, I want to provide a background pattern for my component. If the image is an external resource I could use the background-image in the stylesheet/style method - but it should be provided by Squeak. The <body> is already created as part of the framework, so how can I provide an own one? It's created inside the response object - so there is no renderBodyOn: method in WAComponent I could overwrite. My current solution looks like this: 1. I've added a method providing a ColorForm. 2. implemented renderContentOn: html html document body attributeAt: 'background' put: (html urlForDocument: self resourceProvider stripePattern1x4x4) Is there a better way? Thx Torsten

2 1

DIV actions
by Torsten.Bergmann＠phaidros.com 19 Nov '03

19 Nov '03

Hi, what is the best way to bind a DIV tag "clicked"/script to a smalltalk method? I want to get the same effect as in the Calculator article - clicking on a rectangle without using a special style for active links (since this also changes the links in the toolbar) Thx Torsten

2 1

Re: Which class best suits a simple submission form?
by Torsten.Bergmann＠phaidros.com 19 Nov '03

19 Nov '03

Hi Samuel, have a look at #submitButtonWithAction:text: Note that you have to cover it with a #form: message. Look at WAYesNoDialog for an example. bye Torsten "Samuel Tesla" <samuel(a)alieniloquent.com> wrote in message news:<42110.12.155.144.75.1069177838.squirrel(a)webmail.thoughtlocker.net>... > First off, I love Seaside. It is very very cool. But I'm trying to > follow the examples that are provided to figure out what to do for my > app, and I can't help but think I'm making it too hard for myself. > > What I want to set up is a simple sign up wizard. Each page would > verify the data before committing it to the model. There would be > buttons like in a normal GUI wizard: next, forward, finish, cancel. The > buttons would be active/inactive depending on which screen in the wizard > they were in. > > I know it should be simple and straight forward, but I'm having trouble > figuring out the (presumeably) obvious best way to do it. There are so > many classes to inherit from and so many examples to try and mimic! > > I tried to follow the Store example as it was a multipage app, but the > WABatchedList doesn't seem to really lend itself well. I saw a couple of > classes in the Widgets group that seemed close to it, but they used links > instead of buttons. > > I appreciate any suggestions. > > Thanks, > Samuel Tesla > > > --

1 0

A Day At The Beach
by Sven Van Caekenberghe 15 Nov '03

15 Nov '03

Hi, I have just completed an article, 'A Day At The Beach', describing our first exploration of the Seaside Web Application Framework for Squeak Smalltalk. The article contains source code for a simple four-function calculator web application with full backtracking. http://homepage.mac.com/svc/ADayAtTheBeach/index.html In any case, we think Seaside is really great -- thanks beta4 ! We will certainly be using it in the future. Sven -- Sven Van Caekenberghe - mailto:sven@beta9.be Beta Nine - software engineering - http://www.beta9.be .Mac - svc(a)mac.com - http://homepage.mac.com/svc "Lisp isn't a language, it's a building material." - Alan Kay

3 3

Help!!
by Mario Camerino 14 Nov '03

14 Nov '03

I'm a student from the University of Milan. I would know where I can find some tutorials about Squeak, maybe in Italian. I need something easy to start learn. Thank you so much Camerino Mario _________________________________________________________________ MSN Extra Storage: piena libertà di esprimersi e comunicare http://www.msn.it/msnservizi/es/?xAPID=534&DI=1044&SU=http://hotmail.it/&HL…

1 0

Getting Seaside/Comanche to listen on a single IP address?
by Ian Prince 14 Nov '03

14 Nov '03

Quite a few of the servers I run have multiple IP addresses. Starting Seaside with WAKom startOn:9090 seems to listen to all the defined IP addresses on a server. How can I restrict Seaside/Comanche to listen on a specified ip address? I seem to remember it was a restriction in the lower-level network code - is this still the case? For the moment I'm getting around the issue by running 2 Comanche servers on different ports and using Apache virtual hosts. Just wondering about the possibility of a pure Comanche solution... Ian.

8 9

My Introduction to Seaside
by Ken Treis 13 Nov '03

13 Nov '03

Hello, I'm Ken Treis, and I was one of the original developers of Swazoo (and of WikiWorks before that, together with Travis Griggs). So I've been doing Smalltalk web stuff for a while. But I became somewhat disillusioned of it, and I haven't done any new Smalltalk web development for quite a while. But I've recently discovered Seaside, and I'm already hooked. Most of my recent work has been in the "content" (as opposed to "web app") area, and so PHP+PostgreSQL has been good enough. But when I have tried to push into the web app area, I've quickly discovered the shortcomings of Ptth development. I found that I ended up designing very content-centric applications wherein the user navigates large related data sets; he primarily adds, removes, or changes data items. It's a far cry from what I was used to do in Smalltalk for regular desktop applications. After discovering Seaside, I tried the "walk on the seaside" tutorial and was blown away. My thoughts were: * This is what Swazoo wanted to be, in the end. But we never got there; we didn't make the paradigm shift. * The tutorial is beautifully done, from a pedagogical perspective. There are several "ah-ha" moments as you work through it, but the best is the retroactive one when you realize that the browser, inspector, etc. are all done using #call: from the main counter. * Why did they name this framework after an eggplant (aubergine)? Travis Griggs and I are going to do a Seaside project together, just for grins. And I want to use Seaside in my next major project. But I have a few questions: * What's the best way to tie into a database? I'm not too keen on object-relational mappers; I'd almost rather have something more like a PERL prepare/execute. * How are people deploying Seaside? Is it generally being launched with Comanche handling everything, or is it somehow made subservient to Apache? Could mod_proxy be used for this? * Is this stable enough to be used 24x7? After a while, Swazoo (at least on VisualWorks) would clog up with unreleased socket handles and have to be restarted. I look forward to re-joining the Smalltalk web community. Thanks for making it worthwhile. -- Ken Treis Miriam Technologies, Inc.

7 7

#alwaysRedirect
by Avi Bryant 12 Nov '03

12 Nov '03

One of the design decisions we made very early on when developing Seaside was that by default, every request would be split into two parts: a request would come in, Seaside would issue a redirect, the browser would make a second request, and then Seaside would provide the full response. In very early Seaside, these were known as "action" and "view" requests, because all the processing happens in the first request, and all the rendering happens in the second one. I like to re-evaluate design decisions every once in a while, and I'm wondering whether to stick with this one. The advantage is that a browser reload is always a completely safe operation - it'll only re-issue the "view" request, which means that there can't be any side effects. It also means you're never reloading the result of a POST request, so you never get that annoying "do you want to re-submit?" dialog from the browser. The major disadvantage is that on high latency connections, it can slow down your application noticeably. It's especially bad when compounded by using HTTP Basic Authentication (which seems to double the number of requests in many browsers). The redirecting (which is optional, through the #alwaysRedirect preference) also adds a certain amount of complexity to the framework. What I'm considering is this: by default, links (#anchorWithAction:text:) will not perform this redirect. Forms will continue to use POST by default, and so will insert a redirect. This should significantly cut down on the number of roundtrips for an average Seaside app. There will also be variants of the above: #anchorWithSafeAction:text:, which will perform the redirect (if the action is something that would be bad to repeat on a reload, like adding an item to a shopping cart), and some way of designating a form to use GET instead of POST, for really simple forms (like forms with buttons but no inputs), which will not redirect. Would this be a change for the better, or for the worse? Avi

5 6

Gardner fun
by Brian Brown 11 Nov '03

11 Nov '03

Greetings all, (I'm using Seaside v54, Kom 6.2, Tric-Gardner-CdG.26, Tric-Janus-CdG.4) I am attempting to migrate from Swiki/ComSwiki to Gardner and was wondering about the state of GWSwikiConverter. I did this in a Workspace: GWObjectMemoryStorage wikis removeKey: 'devinfo'. GWSwikiConverter convert: '/Volumes/brian/Squeak/ComSwiki/swiki/devinfo' toWikiInMemory: 'devinfo'. Which worked after I "hacked" some debugs. I use the term "hacked" loosely, due my lack of knowlege regarding Gardner :) In SWWikiParser>>reduceActionForcode1, I commented out: action assertPermission: SWPage permissionCode." Due to the fact that SWPage doesn't exist in my image. Anyway, it seemed to go, (well, the progress bar completed). But now what do I do with it... there was no new wiki created from a seaside perspective, so I assume I have a wiki in memory. So, I tried this: GWSwikiConverter convert: '/Volumes/brian/Squeak/ComSwiki/swiki/devinfo' to: (GWSmartRefStreamStorage newOn: 'devinfo'). Which failed in GWSwikiConverter>>convert with an error about using only integers as indices at: numberToTitle at: each id printString put: each name. page := target at: each id printString. On another note, when I installed it, the default wiki wouldn't work, but when I created a new on via the seaside config, the new one worked. Anyone else using Gardner that could shed some light on things? Thanks! Brian

2 1

VW Port
by Pennell, David 07 Nov '03

07 Nov '03

I just published a port of version 59 from SqueakMap to the Cincom public repository. You can download the Seaside-WebToolKit bundle and all of the pre-requisites will come along. I've smoke tested all of the pre-registered applications and added another round of Squeak extensions to support them. Roger - I believe I've harvested all of your feedback. I'm using VW's EphemeronDictionary - let me know if you still see the random failures. Base64 encoding is now in, but I haven't tested it yet. Has anybody done anything for unit testing Seaside? It sure would be nice to have a test suite to run after one of these porting exercises. -david

4 6

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside November 2003