seaside September 2003

seaside@lists.squeakfoundation.org

20 participants
21 discussions

[Goodie] Janus
by Cees de Groot 26 Dec '03

26 Dec '03

Janus, the two-headed god, makes his entry in Seasideland! http://tai42.xs4all.nl/~cg/mc has the initial MC file for 'Tric-Janus', which is a small package that makes Seaside apps spider-friendly in the following way: It can be used instead of WAKom (so 'JanusKom startOn: 1234'), and inspects every request: - a request for /robots.txt is intercepted (note: forward these requests from Apache!). If the request is made from a known spider, everything is allowed; otherwise, everything is denied - a corresponding text file is returned; - a known spider makes a different request. If yes, the cache of 'static pages' is used to answer the request; - all other requests are passed to the code in WAKom. The 'cache of static pages' needs to be built up by the application. This might be application-dependent - the current solution certainly is, because it assumes that at the time the request is handled, the whole structure of the page is known. JanusSession can be used for Janus-aware subclasses and simply adds a method #addToPath:staticContents which does the same as the original #addToPath:, but also registers the passed static contents in the cache of static pages under the full path. Furthermore, JanusKom has a class-side method to register certain urls as indexes - this can be used to make sure that for certain urls an index rather than a page is returned, which might help in some cases to suck a bot into a site. So, when Janus decides to feed from the static pages cache, it returns a known page under the requested URL (if not overridden as an index URL) or, if no pages is found, an index. An index consists of a list of HREFs to all the static pages in the cache with the same prefix as the requested URL (I'm not sure there whether this is the best solution). Gardner (same MC repository) has been modified to support this. GWSession subclasses from JanusSession and calls #addToPath:staticContents:, and GWPage has a method #renderStatic to support this - the only difference is that this method renders path-based rather than Seaside-based HREFs. The end result should be that Gardner Wikis can be visited by spiders without problems, while still allowing you the freedom to add Seaside bells&whistles. Also, the spiders will not see any of the Wiki buttons etcetera, so they'll pull much less data from your site (they won't have access to all the old versions, for example). Furthermore, this might be a nice way to render static wikis - just hit the site with wget -m (which Janus thinks is a spider) and you get a copy. I've added a list of 158 user agent patterns I grabbed from The InternetOne's webserver logs, if there are any remarks about the list I'll be happy to hear it. There's still work to be done, like not writing the cache on every hit, etcetera, but at this time I'm mostly interested in comments about the operating principle. Regards, Cees

3 3

A question about checkboxes
by Nick Brown 30 Sep '03

30 Sep '03

Hello folks. At work I've recently inherited a project involving the development of a very large and rather complex form residing on an intranet website. Given that the existing project is reliant upon a lot of hand-editted html (there is clint-side JavaScript which interacts with the form components), I'm attempting to use Seaside to come up with a reasonably well factored way of describing the form, allowing the html to be generated automatically. I've only spent a small amount of time working on this, and have had some very encouraging results so far, but I have hit a sticking point. . . There is a requirement for checkboxes on this form, which need to be included in the form results. The only checkboxes that Seaside appears to be able to create using the given methods always have a call-back associated with them, and always cause the entire page to refresh. While I appreciate how useful this can be, in this case I'm concerned that users seeing the page refresh multiple times as they fill it in will be distracting. I'd like to be able to create checkboxes which don't cause a page refresh, but whose value is returned when the form is submitted. I can certainly make Seaside write out the appropriate tags to create a checkbox which can indeed be ticked without causing a page refresh, but how can I then retrieve the status of the checkbox when the form is submitted? More generally, I suppose what I'd like to be able to do is to defer the call-back until the form is submitted, and then receive all the call-backs at once. Is this possible? Thanks for any suggestions, -Nick -- http://www.fastmail.fm - The way an email service should be

2 2

Apache frontend for Squeak, mod_scgi ?
by Jimmie Houchin 29 Sep '03

29 Sep '03

My apologies for a general Squeak web question. But it seems this is where most of the web developers for Squeak are. :) I am currently building a website. I would like to use Squeak but am concerned about performance and stability. Due to that I am seriously (reasonably so) considering using Apache and Python, Quixote to be specific. http://www.mems-exchange.org/software/quixote/ As the sole implementor of this site I like the philosophy of Quixote. Much of the performance of Quixote is from using Apache as the webserver instead of a Python based server. The most popular means of achieving that is via mod_scgi. http://www.mems-exchange.org/software/scgi/ Version 1.2a is available for Apache 1.3 and 2.0.4x http://www.mems-exchange.org/software/files/scgi/ This is the platform LWN uses and achieves good performance, handles Slashdotting, etc. I would like that for Squeak. From my understanding there is 2 parts to SCGI. The Apache module and the client-side code in this case called scgi_server.py. It is only a 268 line file including comments (in the 1.1 version). It appears to be using Netstrings of which Stephen Pair has a Squeak implementation. I believe something like this would help Squeak in web development. Unfortunately I am not currently qualified to port this to Squeak. It might not take someone who is knowledgeable very long to implement. I would fund it but my funds are not much. I am currently funding my server (purchasing next week) and deployment costs. When my site is profitable I could fund it, but then it would be after the fact. However, I could offer a small amount toward such, with it released to the community. I think Apache, mod_scgi, and Squeak could outperform Apache, mod_scgi, and Python. I don't know how this compares to mod_lisp. But mod_lisp also isn't available for Apache2 to my knowledge. Thoughts, opinions, offers, takers? Thanks. Jimmie Houchin

10 20

Goto? (Call without return/answer)
by Giovanni Giorgi 28 Sep '03

28 Sep '03

Hi! I'd like to implement a component goto: call. I need this to go from a form to another (by a main menu bar) Put in other way, I need a call: without answer. I think this should be trivial but how can I get it? Bye bye ;) -- Plus I remember being impressed with Ada because you could write an infinite loop without a faked up condition. The idea being that in Ada the typical infinite loop would normally be terminated by detonation. -Larry Wall [ [ [ JJ ] ] ]

2 1

Re: [ANN] Comanche 6.2
by Avi Bryant 27 Sep '03

27 Sep '03

On Sat, 27 Sep 2003, Lukas Renggli wrote: > > with any web server that uses the HTTP 1.1 keep-alive feature - which > > includes Comanche 6, and will include Swazoo once Lukas integrates my > > keep-alive patch :). > > I will integrate that patch as soon as you send it too me or do I have > to download it from beta4?. I will publish the new version when all the > unit-tests pass :) It's here: http://beta4.com/mc/Swazoo-avi.11.mcz

2 1

Re: [ANN] Comanche 6.2
by Avi Bryant 27 Sep '03

27 Sep '03

Note that to use this version of Comanche with Seaside, you need to get the very latest Seaside revision from SqueakMap, just posted today. This revision fixes a nasty bug that prevented Seaside from working with any web server that uses the HTTP 1.1 keep-alive feature - which includes Comanche 6, and will include Swazoo once Lukas integrates my keep-alive patch :). I know there were some people (including me) that stuck with Comanche 5 because of this problem. Things should be more stable now. Cheers, Avi On Fri, 26 Sep 2003, Stephen Pair wrote: > KomHttpServer 6.2 is now available. It is a small enhancement to make > Comanche work with the new networking code in Squeak 3.6 (it will also > work in older versions of Squeak). Note, it contains a few bug fixes to > Socket and SocketStream. I'll post a separate email later this weekend > with those fixes for consideration for inclusion in 3.6g. > > http://squeaklab.org/comanche/httpserver/index.html > http://map1.squeakfoundation.org/sm/package/0fdb5ffc-cfa1-4d40-96c2-fe325bc… > > - Stephen > > >

1 0

Problems using Seaside
by Juergen Buchner 23 Sep '03

23 Sep '03

Hi, I just started playing around with Seaside. My first problem was, that I use KomHttp V 6.1, but Avi's tutorial assumes Comanche. Finally, I go Seaside running with the following code: | ma seaside | seaside := WAKom default. ma := ModuleAssembly core. ma serverRoot: FileDirectory default fullName. ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: request]]. ma documentRoot: FileDirectory default fullName. ma directoryIndex: 'index.html index.htm'. ma serveFiles. (HttpService startOn: 8080 named: 'httpd') plug: ma rootModule This code comes with the README of KomHttp, but with "WAKom new" (what not works) instead of "WAKom default". After doing that code, I can start http://localhost:8080/seaside/config" and play around with the examples. But when I try to configure my first application I get the following error: -------------- BlockCannotReturn: Block cannot return 11 September 2003 10:27 pm VM: unix - Squeak3.4 of 1 March 2003 [latest update: #5170] Image: Squeak3.4 [latest update: #5170] BlockContext>>cannotReturn: Receiver: [] in HttpAdaptor>>beginConversation Arguments and temporary variables: result: a HttpAdaptor ex: a BlockCannotReturn newResult: nil Receiver's instance variables: sender: Error(Exception)>>handlerAction pc: 82 stackp: 1 nargs: 1 startpc: 78 home: HttpAdaptor>>beginConversation [] in HttpAdaptor>>beginConversation Arguments and temporary variables: response: a HttpResponse request: HttpRequest (URL=/seaside/config; protocol=HTTP/1.1; header=a Dictiona...etc... count: 3 limit: 100 ex: an Error Error(Exception)>>handlerAction Receiver: an Error Arguments and temporary variables: na: 1 handler: [] in HttpAdaptor>>beginConversation returnValue: nil Receiver's instance variables: messageText: 'getData timeout' initialContext: Socket(Object)>>error: resignalException: nil handlerContext: BlockContext>>on:do: tag: nil activeHandler: nil Error(Exception)>>signal Receiver: an Error Arguments and temporary variables: result: nil Receiver's instance variables: messageText: 'getData timeout' initialContext: Socket(Object)>>error: resignalException: nil handlerContext: BlockContext>>on:do: tag: nil activeHandler: nil --- The full stack --- BlockContext>>cannotReturn: [] in HttpAdaptor>>beginConversation Error(Exception)>>handlerAction Error(Exception)>>signal - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Error(Exception)>>signal: Socket(Object)>>error: Socket>>getData:buffer: SocketStream>>pvtGetData [] in SocketStream>>upToAll: BlockContext>>repeat SocketStream>>upToAll: HttpRequest>>readRequestHeaderFrom: HttpRequest>>initializeFromStream: HttpRequest class>>readFromStream: HttpAdaptor>>readRequest [] in HttpAdaptor>>beginConversation BlockContext>>on:do: HttpAdaptor>>beginConversation ------------------------ What is the reason for that error? Kind regards Jürgen

5 4

Technology choice question
by Derek Brans 22 Sep '03

22 Sep '03

I have a client that wants a simple web database application that let's you search for actors based on their height, weight and haircolour. He also wants users to be able to download the application and run it offline on their machine (Windows and Mac), so that actors' phone-numbers can be searched on a set where there's no internet connection. Could Seaside (along with Squeak and database files) be configured to easily download and run locally on a user's machine? Would that be more of a Java applet thing? Thank you in advance, Derek Derek Brans Nerd on a Wire Web Design That's Anything But Square http://nerdonawire.com brans(a)nerdonawire.com 604-874-6463 1-877-NERD-ON-A-WIRE

2 1

RE: Base64 Conversion was Re: [Seaside] VW Seaside problems conti nue
by Pennell, David 15 Sep '03

15 Sep '03

> -----Original Message----- > From: Roger Whitney [mailto:whitney@cs.sdsu.edu] > Sent: Sunday, September 14, 2003 4:35 PM > To: The Squeak Enterprise Aubergines Server - general discussion. > Subject: Base64 Conversion was Re: [Seaside] VW Seaside > problems continue > > > David, > One solution is to use Base64EncodingReadStream of the > Base64Encoding > package (located in goodies/other/PostgreSQL) We would then get: > > Seaside.WADispachcher>>decodeAuthorization: aString > ^(Base64EncodingReadStream on: (aString findTokens: ' > ') last) upToEnd > asString > > and need to add the package as a prereq. of Seaside. Of course this > might make it harder to incorporate changes from the Squeak > version of > Seaside. So it probably would be better to add a Base64MimeConverter > class to aVW-Squeak convertibility section. One could just port the > class Base64MimeConverter class from Squeak but it would be less work > to do: > > Base64MimeConverter class>>mimeDecodeToChars: aReadStream > ^ Base64EncodingReadStream onStream: aReadStream > > And then add: > > Base64EncodingReadStream>>contents > ^self upToEnd asString I was planning to use the Net.Base64StreamEncoder class that is already included with the VW-WebToolKit port. Avi is going to change the core code to displatch through SeasidePlatformSupport>>base64Decode:. > If one also adds the following to the package Seaside/VW-Squeak then > one can access via username & password the configuration page. > > SequenceableCollection>>copyAfter: anElement > "Answer a copy of the receiver from after the first occurence > of anElement up to the end. If no such element exists, answer > an empty copy." > > ^ self allButFirst: (self indexOf: anElement ifAbsent: [^ self > copyEmpty]) We have been attempting to minimize the number of Squeak methods that get dragged into this port.** Yeah, I know that you can't tell it from looking at the size of Seaside/Squeak-VW, but we really did eliminate quite a few things. Given that there is only one sender of #copyAfter:, I would probably just change the sender to use something more conventional. ** For at least 2 reasons: 1) potential license conflicts and 2) packaging conflicts, at least until somebody volunteers to build and maintain an independent Squeak-Compatibility package for VW. > > Array>>sortBy: aBlock > ^self asSortedCollection: aBlock The current plan is to change senders of this method to use #asSortedCollection:

1 0

RE: [Seaside] VW Seaside problems continue
by Pennell, David 14 Sep '03

14 Sep '03

> I enter the username and password I just created in the web > browser and > an exception is raised. The method > Seaside.WADispachcher>>decodeAuthorization: uses (see below) > the class > Base64MimeConverter, which is not in my image. So an exception is > raised when Seaside tries to decode the username and password it was > sent. Does anyone know where to find this class? > > Seaside.WADispachcher>>decodeAuthorization: aString > ^(Base64MimeConverter mimeDecodeToChars: > (ReadStream on: (aString findTokens: ' ') last)) > contents Mea culpa. That one is still on the to-do list. I haven't used the configuration application or authentication so it hasn't bothered me. As to Base64MimeConverter, I need to do a little research on it before deciding what to do. > sortBy: is a Squeak method on arrays, which does not exist in VW. Of > course this is fixed with: > > Array>>sortBy: aBlock > ^self asSortedCollection: aBlock > > But now the two problems begin to make me think that there > may be some > VW-Squeak compatibility package that I am missing. Is this the case? No. #sortBy: is only used by WAApplicationList, and one other place. I just haven't run across it yet. This is a judgement call, but in other situations like this, Avi simply modified Seaside to be more platform neutral. Early versions of the 2.3 port had a lot more Squeak dependencies than does the current version. > > Which reminds me, shouldn't the package Seaside-WebToolKit be > listed as > a prereq for the package Seaside? Seaside-WebToolKit contains the > Seaside namespace, so one can not load Seaside first. Several people expressed a desire for the VW port to not be locked into WebToolKit. If I made Seaside-WebToolKit a prereq for Seaside, then when somebody else adds Seaside-Swazoo, you would be stuck. OK, I just realized that I could just make Seaside be a sub-bundle of Seaside-WebToolKit and you would have your one click load. BTW - Cincom (Alan Knight) was soliciting input on StORE improvements at Smalltalk Solutions. I believe that better tools for browsing the repository were on the list. > I realize that I could make this change on the cincom repository, but > am still new enough at Seaside that I am not sure what I am doing. I'm pretty new at using the public repository, new with Seaside and new with a major platform port. Avi and I are in discussion about ways to simplify the porting process so that future versions can be re-ported as simply as possible. I think the ball is currently in my court... In the meantime, please keep the messages coming.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside September 2003