and optional <base> element. Then, perhaps it should have collection of elements as defined in %head.misc entity. These are script, style, meta, link, object. -- Kamil From alain.fischer@bluewin.ch Mon Apr 1 17:23:36 2002 From: alain.fischer@bluewin.ch (Alain Fischer) Date: Mon, 1 Apr 2002 18:23:36 +0200 Subject: [Seaside] How to work with sessions In-Reply-To: <052F28A0-450C-11D6-B193-00039350B274@bluewin.ch> Message-ID: <D16F74FE-458C-11D6-A151-00039350B274@bluewin.ch> --Apple-Mail-1-716310906 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Here is an implementation of authenticated session with session time-out. --Apple-Mail-1-716310906 Content-Disposition: attachment; filename=AFiAuthenticate.2.cs Content-Transfer-Encoding: quoted-printable Content-Type: application/text; x-mac-creator=522A6368; x-unix-mode=0644; x-mac-type=54455854; name="AFiAuthenticate.2.cs" '=46rom=20Squeak3.2gamma=20of=2015=20January=202002=20[latest=20update:=20= #4743]=20on=201=20April=202002=20at=206:14:46=20pm'!=0DSmalltalk=20= renameClassNamed:=20#AuthenticatePage=20as:=20#AFiAuthenticatePage!=0D= IAComponent=20subclass:=20#AFiAuthenticatePage=0D=09= instanceVariableNames:=20'user=20password=20message=20'=0D=09= classVariableNames:=20''=0D=09poolDictionaries:=20''=0D=09category:=20= 'Seaside-Examples'!=0DSmalltalk=20renameClassNamed:=20#AuthenticatedPage=20= as:=20#AFiAuthenticatedPage!=0DIAComponent=20subclass:=20= #AFiAuthenticatedPage=0D=09instanceVariableNames:=20''=0D=09= classVariableNames:=20''=0D=09poolDictionaries:=20''=0D=09category:=20= 'Seaside-Examples'!=0DSmalltalk=20renameClassNamed:=20= #AuthenticatedSession=20as:=20#AFiAuthenticatedSession!=0DIASession=20= subclass:=20#AFiAuthenticatedSession=0D=09instanceVariableNames:=20'user=20= timeOut=20'=0D=09classVariableNames:=20''=0D=09poolDictionaries:=20''=0D=09= category:=20'Seaside-Examples'!=0D=0D!AFiAuthenticatePage=20methodsFor:=20= 'as=20yet=20unclassified'=20stamp:=20'AFi=204/1/2002=2014:20'!=0D= authenticate=0D=0D=09(self=20isValidUserAndPassword)=0D=09=09ifTrue:=20= [self=20return:=20user]=0D=09=09ifFalse:=20[message=20_=20'Invalid=20= username=20or=20password']=0D!=20!=0D=0D!AFiAuthenticatePage=20= methodsFor:=20'as=20yet=20unclassified'=20stamp:=20'AFi=204/1/2002=20= 16:25'!=0Dhtml=0D=0D=09^=20'=0D=09<h2>Authentication</h2>=0D=09<if=20= condition=3D"@message.notNil">[message]</if>=0D=09<form=20= sea:id=3D"authenticate">=0D=09=09<table=20cellpadding=3D"2">=0D=09=09=09= <tr>=0D=09=09=09=09<td>User:</td>=20<td><input=20sea:id=3D"user"=20= type=3D"text"></td>=0D=09=09=09</tr>=0D=09=09=09<tr>=0D=09=09=09=09= <td>Password:</td>=20<td><input=20sea:id=3D"password"=20= type=3D"password"></td>=0D=09=09=09</tr>=0D=09=09=09<tr>=0D=09=09=09=09= <td></td>=20<td><input=20type=3D"submit"=20value=3D"Authenticate"></td>=0D= =09=09=09</tr>=0D=09=09</table>=0D=09</form>=0D=09'=0D!=20!=0D=0D= !AFiAuthenticatePage=20methodsFor:=20'as=20yet=20unclassified'=20stamp:=20= 'AFi=204/1/2002=2001:16'!=0DisAuthenticationPage=0D=0D=09^=20true!=20!=0D= =0D!AFiAuthenticatePage=20methodsFor:=20'as=20yet=20unclassified'=20= stamp:=20'AFi=204/1/2002=2017:26'!=0DisValidUserAndPassword=0D=0D=09^=20= {'admin'->'secret'.=0D=09'administrator'->'secret'.=0D=09= 'viewer'->'view'.=0D=09'modifier'->'modify'}=0D=09=09anySatisfy:=20= [:each=20|=20each=20key=20=3D=20user=20and:=20[each=20value=20=3D=20= password]]=0D!=20!=0D=0D!AFiAuthenticatePage=20methodsFor:=20'as=20yet=20= unclassified'=20stamp:=20'AFi=204/1/2002=2016:46'!=0Dmessage:=20aMessage=0D= =0D=09message=20:=3D=20aMessage!=20!=0D=0D=0D!AFiAuthenticatedPage=20= methodsFor:=20'as=20yet=20unclassified'=20stamp:=20'AFi=204/1/2002=20= 17:30'!=0Dhtml=0D=0D=09^=20'=0D=09<h1>Hello,=20[session.user]!!!!</h1>=0D= =09<a=20href=3D"@redisplay">redisplay</a><br>=0D=09<a=20= href=3D"@logout">logout</a>=0D=09'=0D!=20!=0D=0D!AFiAuthenticatedPage=20= methodsFor:=20'as=20yet=20unclassified'=20stamp:=20'AFi=204/1/2002=20= 16:26'!=0Dlogout=0D=0D=09^=20session=20logout!=20!=0D=0D= !AFiAuthenticatedPage=20methodsFor:=20'as=20yet=20unclassified'=20stamp:=20= 'AFi=204/1/2002=2017:31'!=0Dredisplay=0D=0D=09^=20nil!=20!=0D=0D=0D= !AFiAuthenticatedSession=20methodsFor:=20'as=20yet=20unclassified'=20= stamp:=20'AFi=204/1/2002=2001:47'!=0DisTimedOut=0D=0D=09^=20timeOut=20= isExpired.=0D!=20!=0D=0D!AFiAuthenticatedSession=20methodsFor:=20'as=20= yet=20unclassified'=20stamp:=20'AFi=204/1/2002=2014:34'!=0Dlogout=0D=0D=09= user=20_=20nil=0D!=20!=0D=0D!AFiAuthenticatedSession=20methodsFor:=20'as=20= yet=20unclassified'=20stamp:=20'AFi=204/1/2002=2017:28'!=0D= timeOutSeconds=0D=0D=09^=2010.=0D!=20!=0D=0D!AFiAuthenticatedSession=20= methodsFor:=20'as=20yet=20unclassified'=20stamp:=20'AFi=204/1/2002=20= 14:24'!=0DupdateTimeOut=0D=0D=09timeOut=20:=3D=20Delay=20forSeconds:=20= self=20timeOutSeconds.=0D=09timeOut=20schedule!=20!=0D=0D= !AFiAuthenticatedSession=20methodsFor:=20'request=20handling'=20stamp:=20= 'AFi=204/1/2002=2017:45'!=0DaboutToViewPage:=20aPage=0D=0D=09((aPage=20= respondsTo:=20#isAuthenticationPage)=20and:=20[aPage=20= isAuthenticationPage])=20ifFalse:=0D=09=09[user=20isNil=20=0D=09=09=09= ifTrue:=20[user=20:=3D=20aPage=20callPage:=20(AFiAuthenticatePage=20= new)]=0D=09=09=09ifFalse:=20[self=20isTimedOut=20ifTrue:=0D=09=09=09=09= [user=20:=3D=20aPage=20callPage:=20(AFiAuthenticatePage=20new=20message:=20= 'Your=20session=20has=20expired')]]].=0D=09self=20updateTimeOut.=0D=09= super=20aboutToViewPage:=20aPage!=20!=0D=0D!AFiAuthenticatedSession=20= methodsFor:=20'initialize-release'=20stamp:=20'AFi=204/1/2002=2014:25'!=0D= initialize=0D=0D=09timeOut=20:=3D=20Delay=20forSeconds:=20self=20= timeOutSeconds.=0D=09timeOut=20schedule.=0D=09super=20initialize!=20!=0D=0D= AFiAuthenticatedPage=20removeSelector:=20#isAuthenticationPage!=0D= AFiAuthenticatedPage=20removeSelector:=20#redraw!=0DAFiAuthenticatePage=20= removeSelector:=20#submit!=0D= --Apple-Mail-1-716310906-- From avi@beta4.com Mon Apr 1 22:43:16 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 1 Apr 2002 13:43:16 -0800 (PST) Subject: [Seaside] How to work with sessions In-Reply-To: <D16F74FE-458C-11D6-A151-00039350B274@bluewin.ch> Message-ID: <Pine.LNX.4.30.0204011343040.6800-100000@cable.beta4.com> On Mon, 1 Apr 2002, Alain Fischer wrote: > > Here is an implementation of authenticated session with session time-out. Thanks; I've merged it into the example in SSVS. From avi@beta4.com Mon Apr 1 23:36:08 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 1 Apr 2002 14:36:08 -0800 (PST) Subject: [Seaside] <head>, <body>, and css In-Reply-To: <3CA83DB8.6000507@volny.cz> Message-ID: <Pine.LNX.4.30.0204011116110.6800-100000@cable.beta4.com> On Mon, 1 Apr 2002, Kamil Kukura wrote: > Hmm, I was thinking about some implicit subcomponent (reachable by > something like "self root htmlHead") that would provide html's head > manipulation. According to HTML4 there should be setting for mandatory > <title> and optional <base> element. Then, perhaps it should have > collection of elements as defined in %head.misc entity. These are > script, style, meta, link, object. It seems a little weird to me to treat the head elements so completely differently from any other html - I think I'd rather be able to reuse the concepts of templates and bindings here too, partly because a lot of the <head> element is still more in the domain of the designer than the developer, and so may well want to be in an external html file. On the other hand, I admit that the head block basically amounts to a bunch of import statements - how horrible a restriction is it to force it to be exactly that? That is, components never directly manipulate the head block, but rather return a list of resources (.css files, .js files) that they want imported? Is that too much of an 80% solution? script blocks can be in the body as easily as the head, and forcing style to be in a separate .css doesn't bother me; titles are a messy issue anyway (which subcomponent gets to choose the title for the whole page?), so meta tags are the only real problem... Hmm. Avi From kamk@volny.cz Tue Apr 2 14:52:07 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 02 Apr 2002 15:52:07 +0200 Subject: [Seaside] GOODS for windows Message-ID: <3CA9B787.7010408@volny.cz> does anybody have binary 'goodsrv.exe' built with patch for Tagged Pointers? I don't have Visual C++ so I can't recompile. -- Kamil From kamk@volny.cz Tue Apr 2 09:45:47 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 02 Apr 2002 10:45:47 +0200 Subject: [Seaside] <head>, <body>, and css References: <Pine.LNX.4.30.0204011116110.6800-100000@cable.beta4.com> Message-ID: <3CA96FBB.9050904@volny.cz> > > >It seems a little weird to me to treat the head elements so completely >differently from any other html - I think I'd rather be able to reuse the >concepts of templates and bindings here too, partly because a lot of the ><head> element is still more in the domain of the designer than the >developer, and so may well want to be in an external html file. > >On the other hand, I admit that the head block basically amounts to a >bunch of import statements - how horrible a restriction is it to force it >to be exactly that? That is, components never directly manipulate the >ad block, but rather return a list of resources (.css files, .js files) >that they want imported? Is that too much of an 80% solution? script >blocks can be in the body as easily as the head, and forcing style to be >in a separate .css doesn't bother me; titles are a messy issue anyway >(which subcomponent gets to choose the title for the whole page?), so meta >tags are the only real problem... > Hmm, to me it seems there could be concept like this: o) <head> section is a template and there is a way to modify inner elements o) there is the mechanism which runs upon page rendering and: - sends to every subcomponent's importing message(s) - collects all the stuff the components want to have be imported - manipulates head's template accordingly -- Kamil From alain.fischer@bluewin.ch Tue Apr 2 23:07:47 2002 From: alain.fischer@bluewin.ch (Alain Fischer) Date: Wed, 3 Apr 2002 00:07:47 +0200 Subject: [Seaside] [ENH] Unnecessary repeat attribut in HTML page Message-ID: <10E267A1-4686-11D6-8BFE-00039350B274@bluewin.ch> Hi Avi, If you take a look at the HTML generated by Seaside, you can see that there is unnecessary repeat attribute for IAVisibleRepeat. This make unnecessary big HTML page. To prevent these attributes I have modified the following method: IAVisibleRepeat>>printContentsTo: page attributes removeKey: 'repeat' ifAbsent: []. self printOpenTagTo: page. super printContentsTo: page. self printCloseTagTo: page. Perhaps it's not the best way to correct this. I let you decide. Have a nice day Alain. From avi@beta4.com Wed Apr 3 00:19:16 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 2 Apr 2002 15:19:16 -0800 (PST) Subject: [Seaside] [ENH] Unnecessary repeat attribut in HTML page In-Reply-To: <10E267A1-4686-11D6-8BFE-00039350B274@bluewin.ch> Message-ID: <Pine.LNX.4.30.0204021508280.11392-100000@cable.beta4.com> On Wed, 3 Apr 2002, Alain Fischer wrote: > Hi Avi, > > If you take a look at the HTML generated by Seaside, you can see that > there is unnecessary repeat attribute for IAVisibleRepeat. This make > unnecessary big HTML page. Thanks Alain, That only happens if you write something like <tr repeat="@item/list">. If you use the sea:id attribute directly, you won't see that effect: <tr sea:id="item/list">. However, making a special case of repeat doesn't make sense because you could actually use any attribute you want in its place - <tr foo="@item/list"> would work just the same. It would be possible to take out all such attributes - right now the macro IAImplicitIDExpansion that changes <tr repeat="@foo"> into <tr sea:id="foo"> maintains the repeat attribute, on the theory that you might be using some attribute you actually needed to stay around. The only example I can think of offhand would be something like <div id="@foo">, except that the CSS macro already creates an id attribute for you, so that case is taken care of. Anyway, if you want to make that global change, then you want to change IAImplicitIDExpansion>>expand: so that the line "aNode attributeAt: attr key put: id" becomes "aNode removeAttribute: attr key". I think I'll make this change in SSVS as well, unless someone offers a good reason not to. Avi From avi@beta4.com Tue Apr 2 21:45:30 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 2 Apr 2002 12:45:30 -0800 (PST) Subject: [Seaside] GOODS for windows In-Reply-To: <3CA9B787.7010408@volny.cz> Message-ID: <Pine.LNX.4.30.0204021240110.7827-100000@cable.beta4.com> On Tue, 2 Apr 2002, Kamil Kukura wrote: > does anybody have binary 'goodsrv.exe' built with patch for Tagged Pointers? > I don't have Visual C++ so I can't recompile. I thought it compiled with some of the free compilers, like Borland? At any rate, although this doesn't help you in the long run, if you set the GC parameters so that they don't ever occur, you should be mostly ok even without the patch. From avi@beta4.com Wed Apr 3 01:58:36 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 2 Apr 2002 16:58:36 -0800 (PST) Subject: [Seaside] ssvs bug Message-ID: <Pine.LNX.4.30.0204021653140.11679-100000@cable.beta4.com> Hey, Just a quick note - if anyone's been using the version from ssvs from the last couple of days, you'd do well to update now. There was a small but annoying bug introduced into callPage: that's now fixed. People using the 0.92 release don't need to worry. Cheers, Avi From kamk@volny.cz Thu Apr 4 07:16:44 2002 From: kamk@volny.cz (Kamil Kukura) Date: Thu, 04 Apr 2002 08:16:44 +0200 Subject: [Seaside] Little (OT) problems Message-ID: <3CABEFCC.1020107@volny.cz> I don't know if someone is using configuration like this: I use commanche server and its ChieftainModule. Two modules are used - IAKom for seaside and StaticFileModule for handling static content that is for now external stylesheet and images. Everything works find but from time to time I see application's page without style. In source the <link> element is okay. Also, yesterday I managed by accident embed in component's template the component itself. It resulted into infinite loop and continuous objects creation. My image grown up from 12 mega to 55 :) Maybe it would nice to have some detection of this.. -- Kamil From avi@beta4.com Thu Apr 4 08:05:07 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 3 Apr 2002 23:05:07 -0800 (PST) Subject: [Seaside] Little (OT) problems In-Reply-To: <3CABEFCC.1020107@volny.cz> Message-ID: <Pine.LNX.4.30.0204032300180.19658-100000@cable.beta4.com> On Thu, 4 Apr 2002, Kamil Kukura wrote: > Also, yesterday I managed by accident embed in component's template the > component itself. It resulted into infinite loop and continuous objects > creation. My image grown up from 12 mega to 55 :) Maybe it would nice to > have some detection of this.. Yeah, the problem is that's sometimes actually useful - if guarded by an <if>, recursive components are good for building trees, etc. However, there are a number of issues right now stemming from the lazy creation of subcomponents that makes this possible, so what I may do is force you to explicitly mark a subcomponent as recursive or lazy if you're using it that way, and precreate all the rest. With that, you could detect at least the simple case of embeddeding a component directly into itself quite easily. From avi@beta4.com Thu Apr 4 08:08:10 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 3 Apr 2002 23:08:10 -0800 (PST) Subject: [Seaside] Little (OT) problems In-Reply-To: <3CABEFCC.1020107@volny.cz> Message-ID: <Pine.LNX.4.30.0204032305370.19658-100000@cable.beta4.com> On Thu, 4 Apr 2002, Kamil Kukura wrote: > I don't know if someone is using configuration like this: I use > commanche server and its ChieftainModule. Two modules are used - IAKom > for seaside and StaticFileModule for handling static content that is for > now external stylesheet and images. Everything works find but from time > to time I see application's page without style. In source the <link> > element is okay. I seem to remember something about Comanche dropping connections if too many come at once, like when asking for a stylesheet directly after asking for a page. I think there was a VM patch that fixed this. But I would recommend using IAModLisp instead of IAKom if you have a lot of static content, so that you can let apache deal with the simple stuff (oh, but you're on windows, aren't you...) From bergel@iam.unibe.ch Thu Apr 4 11:55:11 2002 From: bergel@iam.unibe.ch (Bergel Alexandre) Date: Thu, 04 Apr 2002 12:55:11 +0200 Subject: [Seaside] Question about Comanche & Seaside Message-ID: <20020404105511.GC13686@iam.unibe.ch> I have discover these both app this week end, and I have naturally some questions... Does Comanche and Seaside are scalable. How many connections could be supported ? Regards, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._ Bergel Alexandre http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^ From kamk@volny.cz Thu Apr 4 17:14:43 2002 From: kamk@volny.cz (Kamil Kukura) Date: Thu, 04 Apr 2002 18:14:43 +0200 Subject: [Seaside] weird behavior of <button> Message-ID: <3CAC7BF3.8000100@volny.cz> I have in my component a navigation like this: <div class="center"> <button sea:id="previous" type="submit">< Prev</button> <button sea:id="next" type="submit">Next ></button> </div> For unknown reasons pressing 'Prev' button sends #next message instead of #previous. I checked how parsed template looks like and it is okay. But when I did the same in separate application, everything was okay. Is there some way how to "totally" reset an application? Calling application's #reset doesn't help, there are still lingering components. From julian@beta4.com Thu Apr 4 18:25:39 2002 From: julian@beta4.com (Julian Fitzell) Date: Thu, 04 Apr 2002 09:25:39 -0800 Subject: [Seaside] weird behavior of <button> References: <3CAC7BF3.8000100@volny.cz> Message-ID: <3CAC8C93.5060809@beta4.com> Kamil Kukura wrote: > I have in my component a navigation like this: > > <div class="center"> > <button sea:id="previous" type="submit">< Prev</button> > > <button sea:id="next" type="submit">Next ></button> > </div> > > For unknown reasons pressing 'Prev' button sends #next message instead > of #previous. I checked how parsed template looks like and it is okay. > But when I did the same in separate application, everything was okay. > > Is there some way how to "totally" reset an application? Calling > application's #reset doesn't help, there are still lingering components. Hmm... I tried that template and the buttons don't even submit for me.. IE draws them but doesn't submit when I click them (well of course since there's no target to submit to... But... when I put it in a form (which maybe is what you were doing anyway) I do see the same problem... I'll see if I can track it down. Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From julian@beta4.com Thu Apr 4 18:34:08 2002 From: julian@beta4.com (Julian Fitzell) Date: Thu, 04 Apr 2002 09:34:08 -0800 Subject: [Seaside] weird behavior of <button> References: <3CAC7BF3.8000100@volny.cz> <3CAC8C93.5060809@beta4.com> Message-ID: <3CAC8E90.3030604@beta4.com> Julian Fitzell wrote: > Kamil Kukura wrote: > >> I have in my component a navigation like this: >> >> <div class="center"> >> <button sea:id="previous" type="submit">< Prev</button> >> >> <button sea:id="next" type="submit">Next ></button> >> </div> >> >> For unknown reasons pressing 'Prev' button sends #next message instead >> of #previous. I checked how parsed template looks like and it is okay. >> But when I did the same in separate application, everything was okay. >> >> Is there some way how to "totally" reset an application? Calling >> application's #reset doesn't help, there are still lingering components. > > > Hmm... I tried that template and the buttons don't even submit for me.. > IE draws them but doesn't submit when I click them (well of course > since there's no target to submit to... > > But... when I put it in a form (which maybe is what you were doing > anyway) I do see the same problem... I'll see if I can track it down. > > Julian Ok, more information... When you use <input type='submit'> browsers (IE at least) only submit the submit button that was clicked as part of the form data. When you use <button type='submit'> it seems to submit all the buttons. Because of the order in which things are processed, seaside ends up using the first action that was submitted. Anybody have any idea how <button type='submit'> is supposed to indicate which button was pressed??? Julian From julian@beta4.com Thu Apr 4 18:53:22 2002 From: julian@beta4.com (Julian Fitzell) Date: Thu, 04 Apr 2002 09:53:22 -0800 Subject: [Seaside] Question about Comanche & Seaside References: <20020404105511.GC13686@iam.unibe.ch> Message-ID: <3CAC9312.9050601@beta4.com> Bergel Alexandre wrote: > I have discover these both app this week end, and I have naturally some questions... > > Does Comanche and Seaside are scalable. How many connections could be supported ? > > Regards, > Alexandre > Welcome! I personally would use Apache (with IAModLisp) instead of Comanche if possible, if only because it's more well tested and gives more flexibility in terms of other modules like SSL, and makes it easier to mix static and dynamic content. That said, I haven't had any stability problems with Comanche, just haven't tested it on anything large. As for seaside, it *will* be scalable at some point but so far no one that I know of has really tested how far it will go. Seaside is pretty new technology so people are really just playing with it to see what they can do with it. We're more focused on getting a usable system at the moment than making it super-scalable. We do intended to work on it at some point though so if you feel like testing it and let us know what problems you encounter that will likely speed it along. Avi has done some playing with image segments and has a few ideas in his head so I'd imagine he'll have some more details to share when he wakes up ;) Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From avi@beta4.com Thu Apr 4 19:49:14 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 4 Apr 2002 10:49:14 -0800 (PST) Subject: [Seaside] Question about Comanche & Seaside In-Reply-To: <20020404105511.GC13686@iam.unibe.ch> Message-ID: <Pine.LNX.4.30.0204041044500.19902-100000@cable.beta4.com> On Thu, 4 Apr 2002, Bergel Alexandre wrote: > I have discover these both app this week end, and I have naturally > some questions... > > Does Comanche and Seaside are scalable. How many connections could be > supported ? Well, why don't you try for yourself? Apache comes with the excellent ab (apache benchmarking) program that lets you stress test web servers. I've tried using it to throw a few hundred concurrent connections at Comanche/Seaside without issue. But you should try it for yourself on your machine, and post any interesting results. (There are lots of other load testers out there as well if you don't have apache installed, of course). From nevin@smalltalkpro.com Thu Apr 4 19:44:04 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 04 Apr 2002 11:44:04 -0700 Subject: [Seaside] Question about Comanche & Seaside References: <20020404105511.GC13686@iam.unibe.ch> <3CAC9312.9050601@beta4.com> Message-ID: <3CAC9EF4.1040603@smalltalkpro.com> Julian Fitzell wrote: > Bergel Alexandre wrote: > > I have discover these both app this week end, and I have naturally > some questions... > > > > Does Comanche and Seaside are scalable. How many connections could > be supported ? > > > > Regards, > > Alexandre > > > > Welcome! > > I personally would use Apache (with IAModLisp) instead of Comanche if > possible, if only because it's more well tested and gives more > flexibility in terms of other modules like SSL, and makes it easier to > mix static and dynamic content. That said, I haven't had any stability > problems with Comanche, just haven't tested it on anything large. > I see multiple sides to the "scalability" issue: 1. Scalability in terms of supportable web connections/hits per second. 2. Scalability in terms of readily-available support modules, like SSL or other "security" features. 3. Scalability in terms of the business-rule functionality performed by the site. For example, if you are a large industrial company that sells wafer-fab equipment and chip-creation support products, your site likely will have very little traffic (compared to, say, eBay, yahoo, amazon.com, cnn.com, google, etc.). Consequently, investing a lot of resources to support multi-hundred hits per second, etc., is going to be a waste of resources. On the other hand, the required "functionality" of your wafer-fab site might be large, as your site might actually be a very complicated site with business-rule hooks into GL, AP, AR, Bill-of-materials drill-downs, just-in-time ordering systems, etc. And finally, your wafer-fab site might not even care about SSL, encryption, and the like, since the final customer order would likely be a face-to-face meeting. So, as usual, it just depends. I personally think that Comanche is unsurpassed for the third type of scalability-- no need for Apache at all if that is what you mean by "scalability". As for the first type of "scalability", if all you are doing is serving static pages, Apache is the clear performance winner over Comanche. However, if you wish to also "wire" those pages into a Squeak backend to make them dynamic pages, then including Apache in the mix could potentially add to the overhead as well as just add another layer that can break-- in that case, why not just let Squeak do it all? So, "it just depends". I personally think that most site creators have grandiose dreams of site popularity that never materialize, and so they have a tendency to over-engineer for the first type of scalability, and it typically proves to be a waste of time. In other words, I would be inclined to just use Comanche, unless it can be demonstrated that Comanche just isn't sufficient. As for the comment that Apache makes it easier to mix static and dynamic content, I firmly disagree with that statement, and indeed, I think it is just the opposite-- unless by "dynamic content" you mean the typical "dynamic content" approach used by the rest of the world (cgi, perl, JSP, etc.), rather than letting Smalltalk do it. In that case, of course, it is a true statement. So, "it just depends". Nevin From alain.fischer@bluewin.ch Thu Apr 4 20:32:38 2002 From: alain.fischer@bluewin.ch (Alain Fischer) Date: Thu, 4 Apr 2002 21:32:38 +0200 Subject: [Seaside] Seaside and SUnit In-Reply-To: <Pine.LNX.4.30.0203051319520.8279-100000@cable.beta4.com> Message-ID: <B8F75B38-4802-11D6-B1C3-00039350B274@bluewin.ch> Hi Avi, I want now to see how I can use SUnit with Seaside component and=20 searching this mailinglist, I have found that you have already done some work. I will be very happy if you could share your Seaside testing kit. Have a nice day. Alain PS to Alexandre: Welcome to Seaside it's a funny technology, full of promise. Le Mardi 5 mars 2002, =E0 10:35 , Avi Bryant a =E9crit : > Yes, that would be cool. Presumably in Seaside you could do something > with the existing sea:id - it would be trivial to write a macro that > inserted a testid based on this (we've been thinking about doing > something similar for CSS support, incidentally, although I haven't > thought much yet about where you'd want to insert an "id" by default, > where a "class", etc). > > The other problem with tools like HttpUnit, though, is that they seem = to > assume you have meaningful (and thus predictable) URLs. Testing a=20 > Seaside > application would require a testing framework that could extract the=20= > urls > from the current page and use them to test the next one. Chalk up=20 > another > point for statelessness, I'm afraid... > > In terms of higher level testing, I experimented with a simple system = to > let you interact directly with the page instances, avoiding all the = HTML > and HTTP stuff. Each request is simulated within a "self go: [...]" > block, and the TestCase object makes sure that a "page" instVar is=20 > always > set to the current page. So, an simple test for the calculator = example > might look like > > self go: [page numberPressed: 1]. > self go: [page numberPressed: 0]. > self assert: page current =3D '10'. > self go: [page enter]. > self assert: page stack first =3D 10. > self go: [page current: '20'. page functionPressed: #+]. > self assert: page stack first =3D 30. > > I didn't include this code in the release because, due to a strange > interaction between #ensure: and #callCC:, I had to modify SUnit=20 > slightly > to get it to work and I haven't tested it enough to be certain I = didn't > break anything. If anyone wants it, I can bring it up to date and = post > it. From avi@beta4.com Thu Apr 4 20:58:04 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 4 Apr 2002 11:58:04 -0800 (PST) Subject: [Seaside] Seaside and SUnit In-Reply-To: <B8F75B38-4802-11D6-B1C3-00039350B274@bluewin.ch> Message-ID: <Pine.LNX.4.30.0204041154230.22041-100000@cable.beta4.com> On Thu, 4 Apr 2002, Alain Fischer wrote: > Hi Avi, > > I want now to see how I can use SUnit with Seaside component and > searching > this mailinglist, I have found that you have already done some work. > > I will be very happy if you could share your Seaside testing kit. Ok, I haven't touched it for a while, and it'll take a few minutes to integrate back into the current version. I should have some time to do that later today, I'll have it for you by tonight (err, maybe tomorrow morning, your time ;-). From avi@beta4.com Fri Apr 5 10:37:31 2002 From: avi@beta4.com (Avi Bryant) Date: Fri, 5 Apr 2002 01:37:31 -0800 (PST) Subject: [Seaside] Seaside and SUnit In-Reply-To: <B8F75B38-4802-11D6-B1C3-00039350B274@bluewin.ch> Message-ID: <Pine.LNX.4.30.0204050132440.25793-200000@cable.beta4.com> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1293455216-2008996980-1017999451=:25793 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 4 Apr 2002, Alain Fischer wrote: > Hi Avi, > > I want now to see how I can use SUnit with Seaside component and > searching this mailinglist, I have found that you have already done > some work. > > I will be very happy if you could share your Seaside testing kit. Attached. It does seem to still work, although I haven't used it for quite a while so there may be some problems. As you'll see, it's very simple, but hopefully effective. The most useful thing it does is modify sunitEnsure: to not conflict with continuations; I was uneasy about this, but it turns out I've been running with that modified version for a long time with no issues. Let me know how it works. If you don't have any issues with it, I'll include it in the next release. Cheers, Avi --1293455216-2008996980-1017999451=:25793 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="Seaside-Testing.1.cs" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.30.0204050137310.25793@cable.beta4.com> Content-Description: Content-Disposition: attachment; filename="Seaside-Testing.1.cs" J0Zyb20gU3F1ZWFrMy4yZ2FtbWEgb2YgMTUgSmFudWFyeSAyMDAyIFtsYXRl c3QgdXBkYXRlOiAjNDY1M10gb24gNSBBcHJpbCAyMDAyIGF0IDE6MjQ6NTcg YW0nIQ1UZXN0Q2FzZSBzdWJjbGFzczogI0lBVGVzdENhc2UNCWluc3RhbmNl VmFyaWFibGVOYW1lczogJ3Nlc3Npb24gcGFnZSAnDQljbGFzc1ZhcmlhYmxl TmFtZXM6ICcnDQlwb29sRGljdGlvbmFyaWVzOiAnJw0JY2F0ZWdvcnk6ICdT ZWFzaWRlLVRlc3RpbmcnIQ0NIUlBVGVzdENhc2UgY29tbWVudFN0YW1wOiAn PGhpc3RvcmljYWw+JyBwcmlvcjogMCENSSBwcm92aWRlIHNvbWUgYmFzaWMg aW5mcmFzdHJ1Y3R1cmUgZm9yIHVzaW5nIFNVbml0IHRvIHVuaXQgdGVzdCBT ZWFzaWRlIGFwcGxpY2F0aW9ucy4gIFRvIHVzZSBtZSwgeW91IHdpbGwgd2Fu dCB0bzoNDQktIG92ZXJyaWRlIHRoZSBzdGFydFBhZ2UgbWV0aG9kIHRvIHJl dHVybiBhIG5ldyBpbnN0YW5jZSBvZiBhbiBJQUNvbXBvbmVudCwNdXN1YWxs eSB0aGUgZW50cnkgcG9pbnQgb2YgeW91ciBhcHAuDQ0JLSBwb3NzaWJseSBv dmVycmlkZSB0aGUgc2Vzc2lvbkNsYXNzIG1ldGhvZCB0byByZXR1cm4gdGhl IHNlc3Npb24gY2xhc3MgdXNlZCBpbiB5b3VyIGFwcC4gIFRoaXMgZGVmYXVs dHMgdG8gSUFTZXNzaW9uLg0NVGhlIGN1cnJlbnQgYWN0aXZlIHBhZ2Ugd2ls bCBiZSBzdG9yZWQgaW4gdGhlIHBhZ2UgaW5zdGFuY2UgdmFyaWFibGUsIHRo ZSBzZXNzaW9uIGlzIHN0b3JlZCBpbiBzZXNzaW9uLiAgU2ltdWxhdGUgYSBz aW5nbGUgcGFnZSByZXF1ZXN0IGluc2lkZSBhICNnbzogYmxvY2sgKGJ5IG1h bnVhbGx5IGNhbGxpbmcgdGhlIHNldHRlcnMgYW5kIGFjdGlvbiBtZXRob2Rz IHRoYXQgdGhlIGZvcm0gYW5kIGxpbmsgY2FsbGJhY2tzIHdvdWxkIGludm9r ZSkuICBBZnRlciB0aGUgbWV0aG9kIHJldHVybnMsICJwYWdlIiB3aWxsIGJl IHNldCB0byB0aGUgbmV4dCBwYWdlIHRoZSB1c2VyIHdvdWxkIGhhdmUgc2Vl bi4NDVRoaXMgaGFzIG5vdCBiZWVuIGV4dGVuc2l2ZWx5IHRlc3RlZDsgdGhl cmUgaXMgYSB2ZXJ5IHNpbXBsZSBleGFtcGxlIGluIElBQ2FsY1Rlc3RDYXNl LiENDUlBVGVzdENhc2Ugc3ViY2xhc3M6ICNJQUNhbGNUZXN0Q2FzZQ0JaW5z dGFuY2VWYXJpYWJsZU5hbWVzOiAnJw0JY2xhc3NWYXJpYWJsZU5hbWVzOiAn Jw0JcG9vbERpY3Rpb25hcmllczogJycNCWNhdGVnb3J5OiAnU2Vhc2lkZS1U ZXN0aW5nJyENDSFCbG9ja0NvbnRleHQgbWV0aG9kc0ZvcjogJ0NhbXAgU21h bGx0YWxrJyBzdGFtcDogJ0FCIDEvMzAvMjAwMiAxOTozMichDXN1bml0RW5z dXJlOiBhQmxvY2sNDSAgICAgIiAgIF5zZWxmIGVuc3VyZTogYUJsb2NrIg0J fHJlc3VsdHwNCVtyZXN1bHQgXyBzZWxmIHZhbHVlLiBhQmxvY2sgdmFsdWUu IHJlc3VsdF0NCQlvbjogRXhjZXB0aW9uDQkJZG86IFs6ZXwgYUJsb2NrIHZh bHVlLiBlIHNpZ25hbF0hICENDQ0hSUFUZXN0Q2FzZSBtZXRob2RzRm9yOiAn YXMgeWV0IHVuY2xhc3NpZmllZCcgc3RhbXA6ICdBQiAxLzMwLzIwMDIgMTk6 NDgnIQ1nbzogYUJsb2NrDQlwYWdlIF8gc2Vzc2lvbiB0ZXN0OiBhQmxvY2sh ICENDSFJQVRlc3RDYXNlIG1ldGhvZHNGb3I6ICdhcyB5ZXQgdW5jbGFzc2lm aWVkJyBzdGFtcDogJ0FCIDIvMS8yMDAyIDE1OjAyJyENc2Vzc2lvbkNsYXNz DQleIElBU2Vzc2lvbiEgIQ0NIUlBVGVzdENhc2UgbWV0aG9kc0ZvcjogJ2Fz IHlldCB1bmNsYXNzaWZpZWQnIHN0YW1wOiAnQUIgMS8zMC8yMDAyIDIwOjE4 JyENc2V0VXANCXNlc3Npb24gXyBzZWxmIHNlc3Npb25DbGFzcyBuZXcuDQlw YWdlIF8gc2VsZiBzdGFydFBhZ2UuDQlwYWdlIHNlc3Npb246IHNlc3Npb24u ISAhDQ0hSUFUZXN0Q2FzZSBtZXRob2RzRm9yOiAnYXMgeWV0IHVuY2xhc3Np ZmllZCcgc3RhbXA6ICdBQiAxLzMwLzIwMDIgMjA6MTgnIQ1zdGFydFBhZ2UN CV4gc2VsZiBzdWJjbGFzc1Jlc3BvbnNpYmlsaXR5ISAhDQ0NIUlBQ2FsY1Rl c3RDYXNlIG1ldGhvZHNGb3I6ICdhcyB5ZXQgdW5jbGFzc2lmaWVkJyBzdGFt cDogJ0FCIDEvMzAvMjAwMiAyMDoxOCchDXN0YXJ0UGFnZQ0JXiBJQUNhbGN1 bGF0b3IgbmV3ISAhDQ0hSUFDYWxjVGVzdENhc2UgbWV0aG9kc0ZvcjogJ2Fz IHlldCB1bmNsYXNzaWZpZWQnIHN0YW1wOiAnQUIgMS8zMC8yMDAyIDIwOjI2 JyENdGVzdFNpbXBsZUFkZGl0aW9uDQlzZWxmIGdvOiBbcGFnZSBjdXJyZW50 OiAnMTAnLiBwYWdlIGVudGVyXS4NCXNlbGYgZ286IFtwYWdlIGN1cnJlbnQ6 ICcyMCcuIHBhZ2UgZnVuY3Rpb25QcmVzc2VkOiAjK10uDQlzZWxmIGFzc2Vy dDogcGFnZSBzdGFjayBmaXJzdCA9IDMwLiEgIQ0NIUlBQ2FsY1Rlc3RDYXNl IG1ldGhvZHNGb3I6ICdhcyB5ZXQgdW5jbGFzc2lmaWVkJyBzdGFtcDogJ0FC IDEvMzAvMjAwMiAxOTo1MCchDXRlc3RTaW1wbGVOdW1iZXJFbnRyeQ0gICAg ICAgIHNlbGYgZ286IFtwYWdlIG51bWJlclByZXNzZWQ6IDFdLg0gICAgICAg IHNlbGYgZ286IFtwYWdlIG51bWJlclByZXNzZWQ6IDJdLg0gICAgICAgIHNl bGYgZ286IFtwYWdlIG51bWJlclByZXNzZWQ6IDNdLg0gICAgICAgIHNlbGYg YXNzZXJ0OiBwYWdlIGN1cnJlbnQgID0gJzEyMychICENDQ== --1293455216-2008996980-1017999451=:25793-- From alain.fischer@bluewin.ch Fri Apr 5 14:15:28 2002 From: alain.fischer@bluewin.ch (Alain Fischer) Date: Fri, 5 Apr 2002 15:15:28 +0200 Subject: [Seaside] Seaside and SUnit In-Reply-To: <Pine.LNX.4.30.0204050132440.25793-200000@cable.beta4.com> Message-ID: <32E1C780-4897-11D6-835C-00039350B274@bluewin.ch> Thanks Avi, I will try this and report how it worked for me. Le Vendredi 5 avril 2002, =E0 11:37 , Avi Bryant a =E9crit : > On Thu, 4 Apr 2002, Alain Fischer wrote: > >> Hi Avi, >> >> I want now to see how I can use SUnit with Seaside component and >> searching this mailinglist, I have found that you have already done >> some work. >> >> I will be very happy if you could share your Seaside testing kit. > > Attached. It does seem to still work, although I haven't used it for > quite a while so there may be some problems. As you'll see, it's very > simple, but hopefully effective. > > The most useful thing it does is modify sunitEnsure: to not conflict=20= > with > continuations; I was uneasy about this, but it turns out I've been=20 > running > with that modified version for a long time with no issues. > > Let me know how it works. If you don't have any issues with it, I'll > include it in the next release. > > Cheers, > Avi > From avi@beta4.com Sat Apr 6 00:28:53 2002 From: avi@beta4.com (Avi Bryant) Date: Fri, 5 Apr 2002 15:28:53 -0800 (PST) Subject: [Seaside] [FIX] continuations Message-ID: <Pine.LNX.4.30.0204051517570.30910-200000@cable.beta4.com> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1293455216-2132958628-1018049139=:30910 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <Pine.LNX.4.30.0204051526021.30929@cable.beta4.com> Attached is a fix to a long standing problem with the implementation of continuations in Seaside (triggering the bug is pretty easy - try, in a Seaside component, the code "#(1 2 3) do: [:i | self inform: i asString]"). The problem was that when the stack was copied, references in temps to stack frames (ie, to BlockContexts) still pointed to the old copies. This changeset makes sure that all such references are updated during the copying. This also partially cleans up the conflict between continuations and ensure:, although it is still dangerous, unfortunately, to mix ensure: and the back button. --1293455216-2132958628-1018049139=:30910 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="copyStack.cs" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.4.30.0204051525390.30910@cable.beta4.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="copyStack.cs" DSFDb250ZXh0UGFydCBtZXRob2RzRm9yOiAnY29udGludWF0aW9ucycgc3Rh bXA6ICdBQiA0LzUvMjAwMiAxNTowMichDXJlcGxhY2VUZW1wOiBvbGRUZW1w IHdpdGg6IG5ld1RlbXANCXNlbGYgdGVtcE5hbWVzIHdpdGhJbmRleERvOg0J CVs6dGVtcCA6aSB8DQkJKHNlbGYgdGVtcEF0OiBpKSA9PSBvbGRUZW1wDQkJ CWlmVHJ1ZTogW3NlbGYgdGVtcEF0OiBpIHB1dDogbmV3VGVtcF1dISAhDQ0N IUJsb2NrQ29udGV4dCBtZXRob2RzRm9yOiAnY29udGludWF0aW9ucycgc3Rh bXA6ICdBQiA0LzUvMjAwMiAxNTowMychDWNvcHlTdGFjaw0JfHMgaSBob21l RGVwdGggY29weXwNCXMgXyBzZW5kZXIuDQlpIF8gMC4NCWhvbWVEZXB0aCBf IG5pbC4NCVtzIG5vdE5pbF0gd2hpbGVUcnVlOiBbDQkJcyA9PSBob21lIGlm VHJ1ZTogW2hvbWVEZXB0aCBfIGldLg0JCXMgXyBzIHNlbmRlci4NCQlpIF8g aSArIDFdLg0JY29weSBfIHN1cGVyIGNvcHlTdGFjay4NCWhvbWVEZXB0aCBp Zk5vdE5pbDoNCQlbcyBfIGNvcHkgc2VuZGVyLg0JCWhvbWVEZXB0aCB0aW1l c1JlcGVhdDoNCQkJW3MgcmVwbGFjZVRlbXA6IHNlbGYgd2l0aDogY29weS4N CQkJcyBfIHMgc2VuZGVyXS4NCQlzIHJlcGxhY2VUZW1wOiBzZWxmIHdpdGg6 IGNvcHkuDQkJY29weSBob21lOiBzXS4NCV4gY29weSEgIQ0N --1293455216-2132958628-1018049139=:30910-- From bergel@iam.unibe.ch Sun Apr 7 12:35:52 2002 From: bergel@iam.unibe.ch (Bergel Alexandre) Date: Sun, 07 Apr 2002 13:35:52 +0200 Subject: [Seaside] Question about Comanche & Seaside In-Reply-To: <20020404105511.GC13686@iam.unibe.ch> References: <20020404105511.GC13686@iam.unibe.ch> Message-ID: <20020407113552.GB22941@iam.unibe.ch> Hello all, Thank you for your answers. I know nothing about web services and this kind of stuff. It is why I even do not have any idea how I might test Comanche's scalability. I have worked for industrials with Java Servlet. With Comanche it is incredibly much easier. It is why I was wondering me "there should be some drawbacks". I am very happy that Comanche is not simply a toy... Best regards, Alexandre On Thu, Apr 04, 2002 at 12:55:11PM +0200, Bergel Alexandre wrote: > I have discover these both app this week end, and I have naturally some questions... > > Does Comanche and Seaside are scalable. How many connections could be supported ? > > Regards, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._ > Bergel Alexandre http://www.iam.unibe.ch/~bergel > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^ > _______________________________________________ > Seaside mailing list > Seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/seaside -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._ Bergel Alexandre http://www.iam.unibe.ch/~bergel ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^ From kamk@volny.cz Mon Apr 8 19:12:28 2002 From: kamk@volny.cz (Kamil Kukura) Date: Mon, 08 Apr 2002 20:12:28 +0200 Subject: [Seaside] Little (OT) problems References: <Pine.LNX.4.30.0204032305370.19658-100000@cable.beta4.com> Message-ID: <3CB1DD8C.20306@volny.cz> > > >I seem to remember something about Comanche dropping connections if too >many come at once, like when asking for a stylesheet directly after asking >for a page. I think there was a VM patch that fixed this. But I would >recommend using IAModLisp instead of IAKom if you have a lot of static >content, so that you can let apache deal with the simple stuff (oh, but >you're on windows, aren't you...) > Argh.. I see. I guess there's no problem to arrange Apache with mod_proxy and thus let it to forward all requests for seaside to Commanche. Any other content thus be handled by apachee. And yes, it's for MSWindows as well (I need to see pages in Internet Explorer, that's why Windows). -- Kamil From avi@beta4.com Mon Apr 8 20:24:59 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 8 Apr 2002 12:24:59 -0700 (PDT) Subject: [Seaside] Little (OT) problems In-Reply-To: <3CB1DD8C.20306@volny.cz> Message-ID: <Pine.LNX.4.30.0204081223180.14134-100000@cable.beta4.com> On Mon, 8 Apr 2002, Kamil Kukura wrote: > Argh.. I see. I guess there's no problem to arrange Apache with > mod_proxy and thus let it to forward all requests for seaside to > Commanche. Any other content thus be handled by apachee. And yes, it's > for MSWindows as well (I need to see pages in Internet Explorer, that's > why Windows). Well, you could use mod_proxy, but why not use mod_lisp and cut Comanche out of the loop? From kamk@volny.cz Tue Apr 9 04:53:50 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 09 Apr 2002 05:53:50 +0200 Subject: [Seaside] Little (OT) problems References: <Pine.LNX.4.30.0204081223180.14134-100000@cable.beta4.com> Message-ID: <3CB265CE.9050002@volny.cz> > > >Well, you could use mod_proxy, but why not use mod_lisp and cut Comanche >out of the loop? > Well, I just have my heart for times when Squeak could run without OS (SqueakNOS project :). (http://www.smalltalkpro.com) -- Kamil From jdbell@fareselaw.com Wed Apr 10 14:10:04 2002 From: jdbell@fareselaw.com (Jerry Bell) Date: Wed, 10 Apr 2002 08:10:04 -0500 Subject: [Seaside] April Mail Archives Message-ID: <909E88754E6BD411926B00400531D64A01F142A2@CLEVINGER> Is anyone else having trouble with the bottom part of the April mail archives? My browser gets as far as "weird behavior of" and then just renders three big buttons. Thanks, Jerry From avi@beta4.com Wed Apr 10 19:48:01 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 10 Apr 2002 11:48:01 -0700 (PDT) Subject: [Seaside] April Mail Archives In-Reply-To: <909E88754E6BD411926B00400531D64A01F142A2@CLEVINGER> Message-ID: <Pine.LNX.4.30.0204101144450.19933-100000@cable.beta4.com> On Wed, 10 Apr 2002, Jerry Bell wrote: > Is anyone else having trouble with the bottom part of the April mail > archives? My browser gets as far as "weird behavior of" and then just > renders three big buttons. Yeah, I get the same thing. The actual subject of that message is "weird behavior of <button>". Guess mailman isn't escaping things right. If you sort by subject, that message ends up at the bottom, so you can see everything else. From kamk@volny.cz Sat Apr 13 16:25:19 2002 From: kamk@volny.cz (Kamil Kukura) Date: Sat, 13 Apr 2002 17:25:19 +0200 Subject: [Seaside] logic + templates + ... resources Message-ID: <3CB84DDF.1040804@volny.cz> Simply, have a template: <p>Status: [statusText]</p> and of course there's implicit or explicit binding of statusText to something that results into say one of: 'Okay'. 'Pending'. 'Error'. The beauty just works. Now I feel that separation of logic and content is half-baked. I'm doing something that should be multilingual and now I have in the code those strings of possible status. I have helped myself by creating new special element which has use like this: <local sea:id="ok">Okay</local> <local sea:id="pnd">Pending</local> <local sea:id="err">Error</local> These are at the end of template and it's sort of simple resource. In my own IAComponent I have in the binding block also the part that loads local texts to the class side of the component. And of course this element is silent on its output. So, is it good way to think that along with templates we need also something for storing resources? So far I have in each template's end the resource section but I feel the need for shared resources as well. -- Kamil From julian@beta4.com Sat Apr 13 19:15:59 2002 From: julian@beta4.com (Julian Fitzell) Date: Sat, 13 Apr 2002 11:15:59 -0700 Subject: [Seaside] logic + templates + ... resources References: <3CB84DDF.1040804@volny.cz> Message-ID: <3CB875DF.6010606@beta4.com> Kamil Kukura wrote: > Simply, have a template: > > <p>Status: [statusText]</p> > > and of course there's implicit or explicit binding of statusText to > something that results into say one of: 'Okay'. 'Pending'. 'Error'. The > beauty just works. > Now I feel that separation of logic and content is half-baked. I'm doing > something that should be multilingual and now I have in the code those > strings of possible status. I have helped myself by creating new special > element which has use like this: > > <local sea:id="ok">Okay</local> > <local sea:id="pnd">Pending</local> > <local sea:id="err">Error</local> > > These are at the end of template and it's sort of simple resource. In my > own IAComponent I have in the binding block also the part that loads > local texts to the class side of the component. And of course this > element is silent on its output. > > So, is it good way to think that along with templates we need also > something for storing resources? So far I have in each template's end > the resource section but I feel the need for shared resources as well. Maybe I'm misunderstanding what you're saying here, but it looks like you're trying to define internationalization resource strings within the template. I don't quite understand this since the template is supposed to be a layout template. It seems that the code should be looking up the appropriate language and returning the right string when a component asks for it. Now my guess is just that you don't want to have to hardcode the strings into the code and so are putting it in the template because it seems more external. I would have thought that Squeak had some level of internationalization support built in but I can't find it. How do people do this for other applications? This doesn't feel like something that Seaside should need to support directly. Since you should be able to write a seaside app almost like any other app, you should be able to use whatever internationalization system you would use with any other app. I can see having classes that have methods that return the right string and you could have a class for each language or something but there has to be a better way. Thoughts anyone? Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From kamk@volny.cz Tue Apr 16 07:26:01 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 16 Apr 2002 08:26:01 +0200 Subject: [Seaside] memory eating problem Message-ID: <3CBBC3F9.8030900@volny.cz> I did little test. First I cleared all templates and sessions: IAApplication applications do: [ :app | app reset]. IAPage allSubclasses do: [ :class | class flushTemplateCache ]. Smalltalk garbageCollect. Then I played minesweep game for some time (especially to find all the bombs without Boom :). After this I printed: IAVarStack allInstances size 21459 -- Kamil From avi@beta4.com Tue Apr 16 08:25:45 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 16 Apr 2002 00:25:45 -0700 (PDT) Subject: [Seaside] memory eating problem In-Reply-To: <3CBBC3F9.8030900@volny.cz> Message-ID: <Pine.LNX.4.30.0204152351320.13514-100000@cable.beta4.com> On Tue, 16 Apr 2002, Kamil Kukura wrote: > I did little test. First I cleared all templates and sessions: > > IAApplication applications do: [ :app | app reset]. What's #reset? I assume it's a method you added? > After this I printed: > > IAVarStack allInstances size 21459 Minesweeper is a particularly nasty example for this, since not only does it have a lot of links, but each one is in a separate component, which means that you end up with a few hundred VarStacks for each page view. So that looks like maybe 100 page views worth. Now, you probably don't ever need to actually keep 100 page views of history for a single session. One way to fix this would be to put each individual game into a separate transaction (I'm about to commit a change to SSVS that does exactly that). This should keep memory usage down to reasonable levels. However, you could easily have even nastier examples, involving thousands of links on a page. The VarStack code really needs to be improved for this case. Right now, as the class comment attests, it's extremely inefficient, both in how much storage is allocated in how much of it is copied. One way to improve things would be to somehow combine Callbacks and VarStacks, since there's generally a one-one relationship between instances of each. However, I don't think we can easily get away from storing one object (say, 20 or 30 bytes) for each link or form element on a cached page view. This means that caching more than a few million links concurrently is a problem. I haven't yet had to worry about that level of scalability (say you have 10-page transactions, 100 links per page, you can still have 1000 concurrent sessions). But if it's a real concern, we'll do what we can to address it. Thoughts? Cheers, Avi From jhouchin@texoma.net Tue Apr 16 16:08:06 2002 From: jhouchin@texoma.net (Jimmie Houchin) Date: 16 Apr 2002 10:08:06 -0500 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> Message-ID: <1018969687.12361.137.camel@squirrel> I have not had much opportunity to delve into Seaside, but this message caught my attention when it was posted to the Squeak list. >From my understanding from the below, Seaside does not not have "meaningful URLs" which could be bookmarked? Do I understand correctly? >From my understanding there should be nothing mutually exclusive about having an understandable "meaningful" URLs and (sessions and transactions). One thing I always liked about Zope is the that URLs are understandable and bookmarkable. I like that as a website user. I patently despise ugly, unreadable URLs. Zope is dynamic, sessionable, and transactioning. Do I misunderstand something about Seaside and Zope? I am not current on Zope at the moment. What about Seaside requires non-meaningful URLs? What about the features that Seaside aspires to have requires non-meaningful URLs. URLs which are bookmarkable and emailable are a valuable feature. One that I greatly desire. I don't think that dynamism, et al, require giving up such. (From my naive point of view). Thanks for any help at understanding Seasides point of view on this both technically and philosophically. :) Jimmie Houchin On Thu, 2002-04-04 at 13:47, Avi Bryant wrote: > > On Thu, 4 Apr 2002, Nevin Pratt wrote: > > > >Hmm. By the same logic, Squeak should abandon Morphic and move to the > > >VisualWorks UI framework. > > > > > > > I agree with Tim, simply because he added the qualifier "as much as > > possible" (whatever that means) :-) > > Well, and since I've been suggesting to you off list that we could emulate > what you need from SSP in Seaside, you know that I basically agree as > well. ;-) But I really do think that the "as much as possible" is a lot > closer to the Comanche layer, than to the higher level frameworks. > > For example, Seaside does not have meaningful URLs, stateless operation, > or arbitrary character-level munging of HTML. Now, for a lot of purposes, > giving these things up is perfectly reasonable for everything you get in > return. But if you're building a non-transactional, non-sessioned, mostly > static site that needed to be heavily bookmarked, SSP would make far more > sense than trying to graft those features onto Seaside. I think there are > some fundamental divisions in approach to web development (like > stateful/stateless) that don't necessarily want to be unified. > > (Marcel, feel free to jump in here with your micro-transactions that do > exactly that ;-) > > > From cg@cdegroot.com Tue Apr 16 18:44:49 2002 From: cg@cdegroot.com (Cees de Groot) Date: 16 Apr 2002 19:44:49 +0200 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> <1018969687.12361.137.camel@squirrel> Message-ID: <a9hnuh$8eb$1@home.cdegroot.com> Jimmie Houchin <jhouchin@texoma.net> said: >One thing I always liked about Zope is the that URLs are understandable >and bookmarkable. I like that as a website user. I patently despise >ugly, unreadable URLs. > I've got some very ugly URLs between my bookmarks. I couldn't care less, because the software shows the title of the page, not the URL itself. Any webserver needs to match context at the server side with context at the user side. There are exactly three solutions to do this: - Put it in the URL; - Put it in a cookie; - Submit it with every request through hidden form variables. The latter one is neat, but it means that you cannot have normal <A>-style links anymore; so in practice, you either uglify URL's or make it necessary for the user to enable cookies. Ugly URL's may be ugly, but at least there are no political discussions around ugly URL's or users that have disabled ugly URL's. When relying on cookies, lots of users will barf. Actually, I think it's completely unnecessary that a URL is human readable. To the extent that you need to type them in by hand, that is only necessary for URL's that sit behind bad navigation (for example, you always forget how to get from the frontpage of CompanyA.com to its ProductX page - you need to bookmark or remember the URL); that's bad web design. In all other cases, ugly URL's are OK - you can mail them, bookmark them, etcetera. Most important is they don't get too long, and as such a URL that has http://web.site.com/<some 128bit random number encoded base32> might be much more suitable for mailing and bookmarking than http://web.site.com/some/very/verbose/path/into/an/obscure/sublocation/of/the/website, not? -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B From julian@beta4.com Tue Apr 16 19:04:56 2002 From: julian@beta4.com (Julian Fitzell) Date: Tue, 16 Apr 2002 11:04:56 -0700 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> <1018969687.12361.137.camel@squirrel> Message-ID: <3CBC67C8.7030402@beta4.com> Jimmie Houchin wrote: > I have not had much opportunity to delve into Seaside, but this message > caught my attention when it was posted to the Squeak list. > >>From my understanding from the below, Seaside does not not have > "meaningful URLs" which could be bookmarked? Do I understand correctly? > >>From my understanding there should be nothing mutually exclusive about > having an understandable "meaningful" URLs and (sessions and > transactions). > > One thing I always liked about Zope is the that URLs are understandable > and bookmarkable. I like that as a website user. I patently despise > ugly, unreadable URLs. > > Zope is dynamic, sessionable, and transactioning. > > Do I misunderstand something about Seaside and Zope? > I am not current on Zope at the moment. > > What about Seaside requires non-meaningful URLs? > What about the features that Seaside aspires to have requires > non-meaningful URLs. The reason seaside has ugly URLs as compared to Zope is that in Zope you create a complete html chunk and manually put in links to other pages by name. Seaside is much more dynamic than that. A link is given an id, and the action performed by that link can be changed through bindings. So Seaside needs to generate a URL that uniquely identifies a specific action triggered by a link on a specific instance of a page view. The URLs aren't that ugly, really, they just have a few numbers that uniquely identify exactly what point you are at in the application. > URLs which are bookmarkable and emailable are a valuable feature. One > that I greatly desire. I don't think that dynamism, et al, require > giving up such. (From my naive point of view). Although I agree that websites with bookmarkable URLs are nice I'm not sure I agree that the same is true of web applications, which is what seaside is designed for. It makes no more sense for me to bookmark the point at which I was half done adding a comment to bug 317 in a seaside bug tracker than it does for me to bookmark the point just before I typed "foo" on page 37 of some document in Word. What you need to bookmark is applications, not specific runs of an application and that is simple to do since you can enter an application with a URL as simple as http://foo.com/seaside/bar. You can create as many applications as you want so if you have different points in your application that you want the user to be able to start at you can create simple wrapper components that start in the right place, create a new application and voila. > Thanks for any help at understanding Seasides point of view on this both > technically and philosophically. :) > > Jimmie Houchin So while I also hate websites with ugly URLs in theory, I really can't think of a solution that allows the server to uniquely identify where in time the user is in an application. Remember that Seaside allows backtracking using the browser's back button too, so you can't just remember the current state of the application like you might in a PHP session variable, you actually need to know, when a user clicks on a link, whether they're clicking on it on the current page view or whether they've hit back 10 times and are clicking on it on a page view before having made some other modification to the state. Hope that clears things up a little, Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From cg@cdegroot.com Tue Apr 16 19:57:18 2002 From: cg@cdegroot.com (Cees de Groot) Date: 16 Apr 2002 20:57:18 +0200 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> <1018969687.12361.137.camel@squirrel> <a9hnuh$8eb$1@home.cdegroot.com> Message-ID: <a9hs6e$9ln$1@home.cdegroot.com> Cees de Groot <cg@cdegroot.com> said: >I've got some very ugly URLs between my bookmarks. I couldn't care less, >because the software shows the title of the page, not the URL itself. > I was a bit too quick here, completely overlooked the fact that these ugly URL's tend to have session identifiers in them and thus are invalid two weeks later. Oops. However, this can be dealt with gracefully in a lot of cases by the server - simply create a new session and redirect the user. Or encrypt everything necessary for the session in the ugly URL and forget about keeping it around server-side, so that it effectively never expires. -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B From avi@beta4.com Tue Apr 16 20:07:35 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 16 Apr 2002 12:07:35 -0700 (PDT) Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <a9hs6e$9ln$1@home.cdegroot.com> Message-ID: <Pine.LNX.4.30.0204161206180.13514-100000@cable.beta4.com> On 16 Apr 2002, Cees de Groot wrote: > Cees de Groot <cg@cdegroot.com> said: > >I've got some very ugly URLs between my bookmarks. I couldn't care less, > >because the software shows the title of the page, not the URL itself. > > > I was a bit too quick here, completely overlooked the fact that these ugly > URL's tend to have session identifiers in them and thus are invalid > two weeks later. Oops. However, this can be dealt with gracefully in a lot of > cases by the server - simply create a new session and redirect the user. Or > encrypt everything necessary for the session in the ugly URL and forget about > keeping it around server-side, so that it effectively never expires. Or use ImageSegments to persist old sessions on disk and keep them around for as long as you like (IASegmentCache). From jhouchin@texoma.net Wed Apr 17 04:43:09 2002 From: jhouchin@texoma.net (Jimmie Houchin) Date: 16 Apr 2002 22:43:09 -0500 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <3CBC67C8.7030402@beta4.com> References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> <1018969687.12361.137.camel@squirrel> <3CBC67C8.7030402@beta4.com> Message-ID: <1019014990.12361.260.camel@squirrel> On Tue, 2002-04-16 at 13:04, Julian Fitzell wrote: > Jimmie Houchin wrote: [snip] > The reason seaside has ugly URLs as compared to Zope is that in Zope you > create a complete html chunk and manually put in links to other pages by > name. Seaside is much more dynamic than that. A link is given an id, > and the action performed by that link can be changed through bindings. > So Seaside needs to generate a URL that uniquely identifies a specific > action triggered by a link on a specific instance of a page view. The > URLs aren't that ugly, really, they just have a few numbers that > uniquely identify exactly what point you are at in the application. I believe that is an inaccurate and simplistic view of how Zope operates. Zope serves objects out of its object database. Some of those objects may be compelete html chunks, others are not. The links as you say within Zope, are not necessarily to other pages but are references to objects within its database. Some objects have a view and are viewable, some are not. Objects may be any number of things. Some maybe snippets of a script or html, others images or other binary data. I do not believe that Seaside is necessarily more dynamic than Zope or that Seaside can build apps that Zope can't. Not slamming Seaside, I don't know it well enough. Just trying to clarify Zope. > > URLs which are bookmarkable and emailable are a valuable feature. One > > that I greatly desire. I don't think that dynamism, et al, require > > giving up such. (From my naive point of view). > > Although I agree that websites with bookmarkable URLs are nice I'm not > sure I agree that the same is true of web applications, which is what > seaside is designed for. It makes no more sense for me to bookmark the > point at which I was half done adding a comment to bug 317 in a seaside > bug tracker than it does for me to bookmark the point just before I > typed "foo" on page 37 of some document in Word. > > What you need to bookmark is applications, not specific runs of an > application and that is simple to do since you can enter an application > with a URL as simple as http://foo.com/seaside/bar. You can create as > many applications as you want so if you have different points in your > application that you want the user to be able to start at you can create > simple wrapper components that start in the right place, create a new > application and voila. I think what is a website and what is a web application is somewhat ambiguous and deceiving. The end user doesn't necessarily know which is which in practice. They simple have visited a page and would like to either bookmark it or email the URL. This should be reasonably manageable. ECommerce site, web sites or web apps? Amazon web site or web app? Mixture, combination? If you did Amazon in Seaside is it a web app? Is a page on a specific book web site or web app? Is it an entry point to a web app? Would it be bookmarkable in Seaside? > > Thanks for any help at understanding Seasides point of view on this both > > technically and philosophically. :) > > > > Jimmie Houchin > > So while I also hate websites with ugly URLs in theory, I really can't > think of a solution that allows the server to uniquely identify where in > time the user is in an application. Remember that Seaside allows > backtracking using the browser's back button too, so you can't just > remember the current state of the application like you might in a PHP > session variable, you actually need to know, when a user clicks on a > link, whether they're clicking on it on the current page view or whether > they've hit back 10 times and are clicking on it on a page view before > having made some other modification to the state. I don't know if understand the above accurately. In your example are we talking about an identical link on two different pages or possibly the same page just at a different point in their viewing history? Are actions undone by going back to previous points in viewing? ie: Is state reverted? When I click on the back button does Seaside re-serve the page? Would it be just like it was when I was there before? ie: Would the state be as it was previously or affected by the page forward of it in history? Do you have an example of where this feature has value? Just read Tutorial part 2. Still processing. :) With Amazon via Seaside, I do a search, get a list of books. >From that list of books I click on one and proceed forward and add to shopping cart. I then click back multiple times to get to my list to browse other books. How does #isolate affect that situation? Do I lose going back or lose the add transaction? > Hope that clears things up a little, Well see? :) Unfortunately I am not very Smalltalk proficient yet. Thanks. Jimmie Houchin From jhouchin@texoma.net Wed Apr 17 04:58:37 2002 From: jhouchin@texoma.net (Jimmie Houchin) Date: 16 Apr 2002 22:58:37 -0500 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <a9hs6e$9ln$1@home.cdegroot.com> References: <Pine.LNX.4.30.0204041133380.19902-100000@cable.beta4.com> <1018969687.12361.137.camel@squirrel> <a9hnuh$8eb$1@home.cdegroot.com> <a9hs6e$9ln$1@home.cdegroot.com> Message-ID: <1019015917.12362.276.camel@squirrel> Cees, If you sent the quoted message I did not receive it. So all see is what is below. I have emailed URLs which spanned 3-4 lines in my email client. Yuck. Some webpages have no title. For example I was just reading the Seaside Tutorials. The title is "Untitled". If it weren't for a readable URL it would be unknown. URLs persist and are exchanged. URLs exist in email clients and other Text based apps. Philip Greenspun talks about URLs in his book about web publishing. I don't agree with all he writes, but I agree about much on URLs. I understand that there are times when certain data needs to be embedded in URLs, but I don't think the URL must be extraordinarily long or ugly to accomplish such. I personally like sensible URLs. If possible I would like for whatever I choose to develop my website/app in to have as reasonable URLs as possible. This may be something we agree to disagree on. That's okay too. Jimmie Houchin On Tue, 2002-04-16 at 13:57, Cees de Groot wrote: > Cees de Groot <cg@cdegroot.com> said: > >I've got some very ugly URLs between my bookmarks. I couldn't care less, > >because the software shows the title of the page, not the URL itself. > > > I was a bit too quick here, completely overlooked the fact that these ugly > URL's tend to have session identifiers in them and thus are invalid > two weeks later. Oops. However, this can be dealt with gracefully in a lot of > cases by the server - simply create a new session and redirect the user. Or > encrypt everything necessary for the session in the ugly URL and forget about > keeping it around server-side, so that it effectively never expires. > > > -- > Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> > GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B > _______________________________________________ > Seaside mailing list > Seaside@lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/seaside > From avi@beta4.com Wed Apr 17 06:36:20 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 16 Apr 2002 22:36:20 -0700 (PDT) Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <1019014990.12361.260.camel@squirrel> Message-ID: <Pine.LNX.4.30.0204162217150.13514-100000@cable.beta4.com> On 16 Apr 2002, Jimmie Houchin wrote: > I believe that is an inaccurate and simplistic view of how Zope > operates. Zope serves objects out of its object database. Some of those > objects may be compelete html chunks, others are not. The links as you > say within Zope, are not necessarily to other pages but are references > to objects within its database. I don't know Zope well enough to directly comment. However, links in Seaside can be seen in much the same way: they are references to objects. That is, in general, what a url is: an external way of addressing a particular resource. The trouble with meaningful URLs is that you have to give a meaningful name to each object you want to be able to refer to. This becomes rather limiting: in your code, most of your objects do not have meaningful names, but merely have (meaningless, numeric) memory addresses. If you don't force each object referenced by a URL to be named, you have a lot of flexibility in which objects and how many objects can be directly referenced by URLs. I think Seaside makes good use of this flexibility. > If you did Amazon in Seaside is it a web app? > Is a page on a specific book web site or web app? > Is it an entry point to a web app? > Would it be bookmarkable in Seaside? Just to be clear, there's nothing un-bookmarkable about Seaside URLs. All you have to do is make sure the session stays around for as long as you want that bookmark to be valid. Disk space is cheap: if you want people to be able to save the exact state of their session for a month, I don't see that as a problem. > Are actions undone by going back to previous points in viewing? > ie: Is state reverted? State is not reverted. A large part of state is stored, however. If you go back to an earlier page, you are going back to a copy of the page object as it was when that page was generated. You can use the #freezeTo: method to control exactly how deeply this copy is made. For example, the calculator example preserves the entire calculation stack. By default, a simple shallow copy of the page component is saved. > When I click on the back button does Seaside re-serve the page? > Would it be just like it was when I was there before? If you click the back button and hit reload, the page will be as it was before, unless it relies on some more global state (say, a database, or the current time of day), in which case that will be seen up to date. > Do you have an example of where this feature has value? > With Amazon via Seaside, I do a search, get a list of books. > >From that list of books I click on one and proceed forward and add to > shopping cart. I then click back multiple times to get to my list to > browse other books. > > How does #isolate affect that situation? > Do I lose going back or lose the add transaction? Play with the store example that comes with Seaside. It makes the following choice: within a single purchase, the back button does affect the shopping cart - that is, if you add something to your cart, then hit back, then add something else, the first thing you added is no longer in your cart. One you finish that purchase (click "Done Shopping"), the contents of that cart become fixed, in that none of those pages are accessible any more (and the total tally of purchases made can't be affected). This model probably wouldn't make sense for Amazon: you'd want the cart to persist through the entire session, back button or no. You'd probably want the cart stored in the Session object, which is never copied, rather than the Component objects, which are. However, this behavior might make sense in a point of sale situation: add this item, oops, wrong item, hit back, add a different one. Cheers, Avi From avi@beta4.com Wed Apr 17 06:44:07 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 16 Apr 2002 22:44:07 -0700 (PDT) Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <1019015917.12362.276.camel@squirrel> Message-ID: <Pine.LNX.4.30.0204162236330.13514-100000@cable.beta4.com> On 16 Apr 2002, Jimmie Houchin wrote: > I have emailed URLs which spanned 3-4 lines in my email client. Yuck. <snip> > I understand that there are times when certain data needs to be embedded > in URLs, but I don't think the URL must be extraordinarily long or ugly > to accomplish such. Agreed. Seaside URLs are always relatively short: http://foo.com/seaside/myapp/99/top/53/view is typical. They never get any longer than that. > I personally like sensible URLs. > If possible I would like for whatever I choose to develop my website/app > in to have as reasonable URLs as possible. > > This may be something we agree to disagree on. > That's okay too. I personally prefer not to have to think about mapping an external naming scheme onto every point of my application. I prefer to let the system generate URLs for me, particularly since that opens the possibility of a URL being able to refer of one of 10 million possible states rather than one the 100 or so I can come up with names for. So, yes, I think we must simply disagree on that point. Mind you, for applications that truly do have a relatively small number of possible states (Google is an example of one such application, the Wiki is another), I would certainly prefer meaningful URLs. I just don't deal with applications like that very often. Avi From marcel@metaobject.com Wed Apr 17 13:36:34 2002 From: marcel@metaobject.com (Marcel Weiher) Date: Wed, 17 Apr 2002 14:36:34 +0200 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <a9hs6e$9ln$1@home.cdegroot.com> Message-ID: <C08B179E-51FF-11D6-83DF-00039366F3C0@metaobject.com> On Tuesday, April 16, 2002, at 08:57 Uhr, Cees de Groot wrote: > Cees de Groot <cg@cdegroot.com> said: >> I've got some very ugly URLs between my bookmarks. I couldn't care >> less, >> because the software shows the title of the page, not the URL itself. >> > I was a bit too quick here, completely overlooked the fact that these > ugly > URL's tend to have session identifiers in them and thus are invalid > two weeks later. Oops. However, this can be dealt with gracefully in a > lot of > cases by the server - simply create a new session and redirect the > user. Or > encrypt everything necessary for the session in the ugly URL and forget > about > keeping it around server-side, so that it effectively never expires. Yes, making the page essentially stateless. Many pages have a very limited amount of state that isn't much harder to encode into the URL than a session. Let's say you have a single object that contains the state for a page. Just use key-value coding to encode that object as URL-parameters, encoding the page class itself in the path. The generic logic then unarchives this object from the URL parameters, sets up the page with that object and starts executing. Marcel -- Marcel Weiher Metaobject Software Technologies marcel@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc. From julian@beta4.com Wed Apr 17 15:27:36 2002 From: julian@beta4.com (Julian Fitzell) Date: Wed, 17 Apr 2002 07:27:36 -0700 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list References: <C08B179E-51FF-11D6-83DF-00039366F3C0@metaobject.com> Message-ID: <3CBD8658.5070707@beta4.com> Marcel Weiher wrote: > > On Tuesday, April 16, 2002, at 08:57 Uhr, Cees de Groot wrote: > >> Cees de Groot <cg@cdegroot.com> said: >> >>> I've got some very ugly URLs between my bookmarks. I couldn't care less, >>> because the software shows the title of the page, not the URL itself. >>> >> I was a bit too quick here, completely overlooked the fact that these >> ugly >> URL's tend to have session identifiers in them and thus are invalid >> two weeks later. Oops. However, this can be dealt with gracefully in a >> lot of >> cases by the server - simply create a new session and redirect the >> user. Or >> encrypt everything necessary for the session in the ugly URL and >> forget about >> keeping it around server-side, so that it effectively never expires. > > > Yes, making the page essentially stateless. Many pages have a very > limited amount of state that isn't much harder to encode into the URL > than a session. Let's say you have a single object that contains the > state for a page. Just use key-value coding to encode that object as > URL-parameters, encoding the page class itself in the path. The generic > logic then unarchives this object from the URL parameters, sets up the > page with that object and starts executing. There are certainly cases where this can be done. If all the state is propagated to a DB or if the web application is read-only it is far more likely that you might be able to get away with this. *But*, one of the benefits of Seaside (as far as I'm concerned) is that the user can write it without worrying about what can be encoded in a URL. If I'm writing an application to do something with widgets, I want to use widget classes in all my code... I don't want to have to use id strings so that there is something that can be written out to a URL. Also, I want the user to be able to hit the back button and not screw everything up. Users expect to be able to use the back button when browsing the web and I don't want things to get screwed up when they do. To handle this smoothly, seaside needs to know the complete page view history for a session (or at least however much of it you decide to keep around). You can't possibly encode all that information in a URL. So while I agree nice pretty meaningful URLs that you can logically return to at any point would be nice, I really don't think there's a way to achieve that and still have the benefits of seaside. And to me, the benefits are worth the sacrifice. Also, as avi pointed out, as long as you cache the sessions, there is nothing to prevent someone from bookmarking a seaside page and returning to it later. And because you can hit back and then branch off again, you can go to the bookmarked page and carry on as if you'd never done so before. Assuming that is logical in the context of a particular application. This is another advantage. If the context of the application dictates that it doesn't make sense to be at this place more than once, then the developer would have put it in a transaction and if you went to that bookmark you would be redirected to wherever you last were in the application. Seaside URLs are: - short - not particularly ugly (they don't have 30 ?foo=bar&baz=bar style parameters on the end, which I really don't think makes for cleaner URLs) - very much meaningful (just not to a human) - bookmarkable (when appropriate and logical to do so) That said, Seaside is a web application framework, not a website framework. If having one URL for each page is what you want (and I know this isn't what you were saying Marcel, I'm just responding to other messages in this thread) then seaside is just not your solution. If you want to write a web app and you don't want to have to even *think* about URLs, CGI parameters, URL parsing, session persistance, etc, etc, etc then seaside might do it for you (it certainly does for me). And yes, there is a very fuzzy line between what constitutes a web app and what does not. To me, the difference is that a web site is something you go to to get information and therefore may want to return to the same page to get the same information. A web app is something that you run to get something done. And since you don't want to do the same thing again, you don't need to return to where you were last week. You just connect to the application again and do something else when you need to. That said, I have wondered about having a mechanism to initialize an application with parameters in the URL. That way you could have links on a web page that configured the app for a particular skin, or opened it to view a particular object (based on its id in a table), or allowed you to specify a string to search for, or... All of this can be accomplished by having multiple applications defined or by making your entry page part of the application but allowing this feature might make it easier to integrate smaller seaside apps into non-seaside web pages. Making it easier to have a mixture of seaside and non-seaside content would help prevent people from feeling like seaside needs to accomplish all their web needs, IMO. Thoughts? Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From marcel@metaobject.com Wed Apr 17 17:41:53 2002 From: marcel@metaobject.com (Marcel Weiher) Date: Wed, 17 Apr 2002 18:41:53 +0200 Subject: [Seaside] Meaningful URLs was (Re: HV intro...) on the Squeak list In-Reply-To: <3CBD8658.5070707@beta4.com> Message-ID: <05E42394-5222-11D6-83DF-00039366F3C0@metaobject.com> On Wednesday, April 17, 2002, at 04:27 Uhr, Julian Fitzell wrote: > Marcel Weiher wrote: >> Yes, making the page essentially stateless. Many pages have a very >> limited amount of state that isn't much harder to encode into the URL >> than a session. Let's say you have a single object that contains the >> state for a page. Just use key-value coding to encode that object as >> URL-parameters, encoding the page class itself in the path. The >> generic logic then unarchives this object from the URL parameters, >> sets up the page with that object and starts executing. > > There are certainly cases where this can be done. Yes. What we discovered during the development of NPS ( a content management system, www.infopark.com ) is that the cases are *much* more common than we had originally thought. > If all the state is propagated to a DB or if the web application is > read-only it is far more likely that you might be able to get away with > this. My contention is that you can get away with this a lot more than you think, and get a much better user-experience as a result. Once again, this is a result that we hadn't expected, but found to be true. > *But*, one of the benefits of Seaside (as far as I'm concerned) is that > the user can write it without worrying about what can be encoded in a > URL. If I'm writing an application to do something with widgets, I > want to use widget classes in all my code... I don't want to have to > use id strings so that there is something that can be written out to a > URL. Hmm, why should automatic mechanisms stop working just because you're encoding state in the URL? I realize that this perception is common, because the 'comfortable' web-development tools (like WebObjects, for example) are primarily session-based and don't implement running session-less particularly well. Anyway, the issue isn't really how much you can encode, more typically is the case that you have to rethink your app a little from a typical procedural mind-set to a more pure functional mind-set. This is not necessarily a bad thing. > Also, I want the user to be able to hit the back button and not screw > everything up. When you're stateless, the back-button ceases to be a problem. > Users expect to be able to use the back button when browsing the web > and I don't want things to get screwed up when they do. To handle this > smoothly, seaside needs to know the complete page view history for a > session (or at least however much of it you decide to keep around). > You can't possibly encode all that information in a URL. You don't need to do that when you're stateless. In fact, the back button was one of the incentives we had for moving our app towards statelessness. > So while I agree nice pretty meaningful URLs that you can logically > return to at any point would be nice, I really don't think there's a > way to achieve that and still have the benefits of seaside. I disagree. Having built a web-framework and applications using that framework, I am pretty certain that it can be done. The framework wasn't as comfortable as Seaside (or WO for that matter), but the issues were largely orthogonal. > And to me, the benefits are worth the sacrifice. You don't have to sacrifice. > Also, as avi pointed out, as long as you cache the sessions, there is > nothing to prevent someone from bookmarking a seaside page and > returning to it later. Only with unlimited storage. > And because you can hit back and then branch off again, you can go to > the bookmarked page and carry on as if you'd never done so before. > Assuming that is logical in the context of a particular application. > This is another advantage. If the context of the application dictates > that it doesn't make sense to be at this place more than once, then the > developer would have put it in a transaction and if you went to that > bookmark you would be redirected to wherever you last were in the > application. Good you mention transactions, because the system we had developed also had what we call micro-transactions: when actual significant edits were to be performed, a micro-transaction would be created that would typically persist for 2-3 page-views. This would also not be repeatable, with the statlessness around it not being affected. > Seaside URLs are: > - short > - not particularly ugly (they don't have 30 ?foo=bar&baz=bar style > parameters on the end, which I really don't think makes for cleaner > URLs) I don't consider the visual aesthetics of URLs that much of a concern. > - very much meaningful (just not to a human) Stateless URLs are also meaningful and can even be parsed/created by humans. > - bookmarkable (when appropriate and logical to do so) Not really. > That said, Seaside is a web application framework, not a website > framework. I don't believe this is a meaningful distinction in this context. It is an easy trap to fall into because that is how most of the (visible) world looks, but there is actually nothing inherent about it. > If having one URL for each page is what you want (and I know this > isn't what you were saying Marcel, I'm just responding to other > messages in this thread) then seaside is just not your solution. If > you want to write a web app and you don't want to have to even *think* > about URLs, CGI parameters, URL parsing, session persistance, etc, etc, > etc then seaside might do it for you (it certainly does for me). The interesting thing is that these issues are *orthogonal*. > And yes, there is a very fuzzy line between what constitutes a web app > and what does not. Exactly. We found that the line went straight through our app, and my experience so far strongly suggests that the same is true for most web applications. > To me, the difference is that a web site is something you go to to get > information and therefore may want to return to the same page to get > the same information. A web app is something that you run to get > something done. Sorry, I don't see a difference. Getting something usually involves going to some page, looking at lots of information and then changing a little bit of it. As a matter of fact, you're going to have a difficult changing a lot of information via the web, the bandwidth of the UI is pretty limited. > And since you don't want to do the same thing again, you don't need to > return to where you were last week. You just connect to the > application again and do something else when you need to. Once again, we found that this wasn't true. Different people had different areas of the app that they had to deal with, and forcing a sequence of operations was not an enhancment to their user-experience. > That said, I have wondered about having a mechanism to initialize an > application with parameters in the URL. That way you could have links > on a web page that configured the app for a particular skin, or opened > it to view a particular object (based on its id in a table), or allowed > you to specify a string to search for, or... This is actually exactly what I am saying, except that you re-initialize the app as much as possible... > All of this can be accomplished by having multiple applications > defined or by making your entry page part of the application but > allowing this feature might make it easier to integrate smaller seaside > apps into non-seaside web pages. Making it easier to have a mixture of > seaside and non-seaside content would help prevent people from feeling > like seaside needs to accomplish all their web needs, IMO. Thoughts? Exactly, the boundary is fluid, and the it should be easy to cross the boundary from completey static to stateless to stateful. Marcel -- Marcel Weiher Metaobject Software Technologies marcel@metaobject.com www.metaobject.com Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc. From kamk@volny.cz Thu Apr 18 17:01:21 2002 From: kamk@volny.cz (Kamil Kukura) Date: Thu, 18 Apr 2002 18:01:21 +0200 Subject: [Seaside] newSessionOn: (was Meaningful URLs) References: <Pine.LNX.4.30.0204171139280.19539-100000@cable.beta4.com> Message-ID: <3CBEEDD1.5050307@volny.cz> This is a multi-part message in MIME format. --------------050807040105000000010507 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > >>The question is if session key should be as short as that. Someone >>getting session 99 can easy imagine there may be already session 100 and >>trying to get there by changing URL or cookie. >> >Very true. It shouldn't, I'm just lazy. It may want to be some hash of >the client IP, date, etc, so that you can prevent such attacks if >necessary. Patches are accepted, otherwise I'll fix it by the next >release. > Attached is #newSessionOn: which generates 80-bit number encoded in base64. It uses IARequest>>headerAt: for looking up the host name and I am not sure how is it with requests from IAModLisp. -- Kamil --------------050807040105000000010507 Content-Type: text/plain; name="IAApplication-newSessionOn.st" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="IAApplication-newSessionOn.st" 'From Squeak3.0 of 4 February 2001 [latest update: #3552] on 18 April 2002 at 5:58:53 pm'! !IAApplication methodsFor: 'session handling' stamp: 'KamK 4/18/2002 17:56'! newSessionOn: request | bytesOf newSession seeds counter sessionKey | bytesOf _ [:int | | length ba | length _ int digitLength. ba _ ByteArray new: length. 1 to: length do: [:i | ba at: i put: (int digitAt: i)]. ba]. newSession _ sessionClass new application: self. seeds _ (request headerAt: 'host'), (bytesOf value: newSession hash), (bytesOf value: Time millisecondClockValue). counter _ 16rFFFFFFFFFFFFFFFF atRandom. [ | hash foldedHash | counter _ counter + 1. hash _ SecureHashAlgorithm new hashMessage: seeds, (bytesOf value: counter). foldedHash _ RWBinaryOrTextStream on: (ByteArray new: 10). 1 to: 10 do: [:i | foldedHash nextPut: ((hash digitAt: i) bitXor: (hash digitAt: i+10))]. sessionKey _ ((Base64MimeConverter mimeEncode: foldedHash) "avoid unacceptable (/) up to padding (=)" contents copyUpTo: $=) replaceAll: $/ with: $-. (sessions at: sessionKey) notNil ] whileTrue. sessions at: sessionKey put: newSession. ^ sessionKey ! ! --------------050807040105000000010507-- From avi@beta4.com Fri Apr 19 10:20:23 2002 From: avi@beta4.com (Avi Bryant) Date: Fri, 19 Apr 2002 02:20:23 -0700 (PDT) Subject: [Seaside] newSessionOn: (was Meaningful URLs) In-Reply-To: <3CBEEDD1.5050307@volny.cz> Message-ID: <Pine.LNX.4.30.0204190213150.27200-100000@cable.beta4.com> On Thu, 18 Apr 2002, Kamil Kukura wrote: > Attached is #newSessionOn: which generates 80-bit number encoded in > base64. It uses IARequest>>headerAt: for looking up the host name and I > am not sure how is it with requests from IAModLisp. Thanks! With the time in milliseconds folded into the hash, though, won't it be impossible to ever generate anything to compare it with, later? I was thinking more like today's date. Otherwise, I don't see how we could ever tell if the session was being accessed from the same IP or not, etc. Forgive me if I'm missing something obvious. Avi From kamk@volny.cz Fri Apr 19 17:06:13 2002 From: kamk@volny.cz (Kamil Kukura) Date: Fri, 19 Apr 2002 18:06:13 +0200 Subject: [Seaside] newSessionOn: (was Meaningful URLs) References: <Pine.LNX.4.30.0204190213150.27200-100000@cable.beta4.com> Message-ID: <3CC04075.9000802@volny.cz> > > >With the time in milliseconds folded into the hash, though, won't it be >impossible to ever generate anything to compare it with, later? I was >thinking more like today's date. Otherwise, I don't see how we could ever >tell if the session was being accessed from the same IP or not, etc. > There is even semirandom 64-bit integer. I think the best would be to store IP or hostname directly to the session object. -- Kamil From avi@beta4.com Sun Apr 21 01:03:47 2002 From: avi@beta4.com (Avi Bryant) Date: Sat, 20 Apr 2002 17:03:47 -0700 (PDT) Subject: [Seaside] state of the aubergine Message-ID: <Pine.LNX.4.30.0204201631500.1405-100000@cable.beta4.com> Since there's not a huge amount of activity on this list, it's somewhat hard to gauge just what's going on out there, seaside-wise. So I thought I'd throw some questions out that might help me figure out, as I amass little bits of time here and there to work on this stuff, what I should be doing. First of all, how many of you are actively using Seaside? There are 35 or so people on this list, but Kamil and Alain are the only ones that I know have gone much further than looking through the tutorials. It would be good to have a better idea of where you guys are at, how interested you are, what's holding you back from using it more, etc. Second of all, what should I be doing in the documentation department? I know that, eg, a tutorial on using subcomponents is long overdue, but have people managed to figure them out from the examples anyway? Would it be useful, when I don't have time for a full tutorial, for me to start throwing out random short descriptions of features that people might otherwise not know about? For example: ----------------------- BodyContent. Each embedded subcomponent has an implicit BodyContent element. This is used to insert the contents appearing inside the subcomponent's tag inside the parent template. For example, if you had a (rather useless) BoldItalicPage, you might use it in the parent template like so: SomePage>>html ^ '<BoldItalicPage sea:id="sub">foo</BoldItalicPage>' in which case, if you used BodyContent like so: BoldItalicPage>>html ^ '<b>[BodyContent]</b><i>[BodyContent]</i>' the final output would be <b>foo</b><i>foo</i>. You can also bind values to the BodyContent element; if you do, these will appear as template-local variables in the scope of the body content of the parent element. As another silly example, if you have the following template in the parent: SomePage>>html ^ '<BindToXPage sea:id="sub">this is a test: [x]</BindToXPage> and the following bindings in the child: BindToXPage>>addBindingsTo: template (template elementNamed: 'BodyContent') set: #x to: 'foo' and the following template in the child: BindToXPage>>html ^ '<b>[BodyContent]</b>' Then you would get the following output: <b>this is a test: foo</b> --------------------------------------------------- Third of all, what are the features that Seaside needs before people feel comfortable doing development in it? One obvious lack is good persistence support. For example, if it came with a lightweight object-relational mapping system, would it suddenly become much more viable? What if there were a connection to Oracle? What if there were a Squeak port of GLORP? Or, what if there were a VisualWorks port of Seaside? I'm asking all of this because currently, development on Seaside is almost exclusively motivated by the needs of my projects, which may or may not have any bearing on the needs of others. I encourage y'all to speak out so that this can change. Email me privately or respond to the list, but I'd like to hear from you. Cheers, Avi From frank@canyon-medical.com Sun Apr 21 03:46:06 2002 From: frank@canyon-medical.com (Frank Sergeant) Date: Sat, 20 Apr 2002 20:46:06 -0600 Subject: [Seaside] state of the aubergine Message-ID: <200204210143.g3L1hrLA026902@mail3.centurytel.net> Avi Bryant <avi@beta4.com> wrote: > Since there's not a huge amount of activity on this list, it's somewhat > hard to gauge just what's going on out there, seaside-wise. So I thought Yes, I have been awfully quiet, which does not reflect the great goodwill I feel toward you and this project. > First of all, how many of you are actively using Seaside? I am not using it actively yet but I think I will in the future. I read the first tutorial but I haven't yet worked through it for real. > good to have a better idea of where you guys are at, how interested you > are, I am very interested. > what's holding you back from using it more, etc. Mainly that I am swamped and have way too much to do (or that I am way too inefficient and lazy, which probably means the same thing). I seem to be getting further behind rather than getting caught up. > Second of all, what should I be doing in the documentation department? The more, the better, in general. At this point, I am the one who is lagging, not you. > Would it be > useful, when I don't have time for a full tutorial, for me to start > throwing out random short descriptions of features that people might > otherwise not know about? Yes, I think this is a great idea. I save all the messages on this list for the future. > For example: > > ----------------------- > BodyContent. Each embedded subcomponent has an implicit BodyContent I read through this example but only quickly (with the same excuse as given above). I couldn't quite wrap my mind around what it was doing. That is most likely my fault and should be fixed when I get a chance to work through a small application on my own. > Third of all, what are the features that Seaside needs before people feel > comfortable doing development in it? One obvious lack is good persistence > support. That isn't stopping me. I am leaning toward doing something along the lines of Prevayler that has been discussed here. I also have a Python/Metakit database server I could use also (which I am using currently with a Dolphin application). > For example, if it came with a lightweight object-relational > mapping system, would it suddenly become much more viable? What if there > were a connection to Oracle? What if there were a Squeak port of GLORP? None of those are of interest to me (at this time). I have done enough of the object-to-relational (basically following the approach described in Chamond Liu's book) that I believe I'll prefer the simplicity of keeping all the objects in RAM (but logging the actions, a la Prevayler, for full recovery). I have the luxury in the application I have in mind that the data will fit in RAM and realize there could be situations where that wouldn't be suitable. (I am reminded of a book I read many years ago that had a lovely quote along the lines of 'Sometimes you need things but sometimes you only need things because your *things* need things'.) > Or, what if there were a VisualWorks port of Seaside? No, don't bother for me. I would most likely use Squeak. I am still annoyed over Cincom's lack of clarity and lack of straightforwardness with regard to their licensing terms and prices. As far as I am concerned, it shifts far too much of the sales burden to the prospect. > I'm asking all of this because currently, development on Seaside is almost > exclusively motivated by the needs of my projects, This is completely satisfactory to me. I would rather the "single vision" over a "designed by committee" approach. That tends to keep it leaner and cleaner and more understandable, which then makes it easier for each of us to customize it if we really do have different needs. At the same time, the more you explain what and why you are doing, the better. Say, what exactly are you using Seaside for? That might help further put it into perspective for how we might be able to use it. I hope my enhusiasm for the project is more encouraging than my inertia is discouraging. -- Frank From avi@beta4.com Sun Apr 21 03:08:04 2002 From: avi@beta4.com (Avi Bryant) Date: Sat, 20 Apr 2002 19:08:04 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <200204210143.g3L1hrLA026902@mail3.centurytel.net> Message-ID: <Pine.LNX.4.30.0204201850400.1739-100000@cable.beta4.com> On Sat, 20 Apr 2002, Frank Sergeant wrote: > Say, what exactly are you using Seaside for? That might help > further put it into perspective for how we might be able to use it. We're currently finishing up a Seaside application that manages ticket sales for a group of theatres - basically a point of sale app, which has to lead box-office agents through possibly complex combinations of sales, subscriptions, exchanges, etc, as well as providing a lot of reporting. One of the things that surprised me about it was that even though the processes are quite sequential, there ended up being essentially no coupling between the various pages. Instead, the application is structured as a bunch of dialogs with simple inputs and simple outputs (eg, a page which is given a performance, and returns a set of seats, or a page which is given a dollar amount and returns a set of payment records). A completely different set of objects models the control flow paths of particular transactions by calling these dialogs in sequence. Obviously this is the whole point of the callPage:/return: system, but it was the first time I'd put it into practical use, and it was very interesting to see what a huge difference it made to the overall structure of the app. I'll be using Seaside for some other stuff this summer, but I probably shouldn't talk about it yet ;-). From nevin@smalltalkpro.com Sun Apr 21 03:53:36 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Sat, 20 Apr 2002 20:53:36 -0600 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204201631500.1405-100000@cable.beta4.com> Message-ID: <3CC229B0.2070401@smalltalkpro.com> Avi Bryant wrote: >Since there's not a huge amount of activity on this list, it's somewhat >hard to gauge just what's going on out there, seaside-wise. So I thought >I'd throw some questions out that might help me figure out, as I amass >little bits of time here and there to work on this stuff, what I should be >doing. > >First of all, how many of you are actively using Seaside? There are 35 or >so people on this list, but Kamil and Alain are the only ones that I know >have gone much further than looking through the tutorials. It would be >good to have a better idea of where you guys are at, how interested you >are, what's holding you back from using it more, etc. > Well, maybe I'll talk a bit about what I have so far. First, I am using Squeak to serve my site: http://www.smalltalkpro.com. Now, I'll admit that most of the rhetoric on my site is specifically addressed as a propoganda piece for the employees at my current gig (a *cough* Java gig). In other words, I don't really talk about Smalltalk or Squeak at my current gig-- I just point people to my site. I update my site to suit the conversations that are taking place at work. So, it is just a propoganda piece-- what I call a part of my "propoganda machine", whose propoganda is specifically tailored to my current (*cough*) Java gig. As a propoganda machine, it is important to be able to showcase a *Smalltalk only* solution (with the exception of the html generation). Thus, I won't tolerate Apache, Tomcat, or anything else. It must be Squeak *only*-- otherwise it loses it's propoganda effect. As a propoganda piece, it is also important to be able to separate the work done by a Graphics Designer from the work done by a Smalltalk Programmer. Furthermore, the Graphics Designer needs to be able to use any tool of his/her choice (Dreamweaver, FrontPage, or whatever), and the Programmer can take the html created from that tool and wire it to the backend. This is an *absolute* unnegotiable requirement at my Java gig, and thus it will also be an *absolute* unnegotiable requirement for my Smalltalk propoganda machine. My wife's site (http://www.bountifulbaby.com) is also being served by the same server as my site. Besides it being a good sideline business for her, it is also actually part of my propoganda machine. At my current (cough) Java gig, they have several people working on an online catalog ordering system. My wife's site is also going to be expanded into roughly the same kind of catalog ordering system we are doing at work. The goal is to stay slightly ahead (functionality-wise) of what they have developed at work. And, do it with a 12 year old boy (my son Adam) working on it part time after school (but with my guidance). If Adam can work part-time, and yet produce more functionality that they have at any given time on the project at work (thus keeping ahead of the expensive "professional Java team" at work), it will have a "slam-dunk" effect on the project at work when management gets wind of it. That's what I am doing, and so far it is working. And, it is already beginning to stir some interest at work. And, I'm enjoying the effect immensely. It is a source of pride for me watching it actually happen. OK, from this description, there are a number of things that become evident. First, we *have* to be able to support virtual hosts (the gig at work likewise does). Thus, if you check the IP for "smalltalkpro.com" as well as "bountifulbaby.com", you will see they both point to the same machine--my server machine. The squeak server therefore must be able to synthesize a different "document Root" based on the incoming URL. This is how I've done that: docRootForRequest: aRequest "For virtual domain support, we need to map a host to a local directory. This is how. There are numerous other ways this could have been done, but doing it this way means I don't have to update the map when I add another host. All I have to do is make sure the appropriate directory exists in '/home' (smalltalkpro, bountifulbaby, or whatever matches the host portion of the URL just before the .com or .org), plus make sure that directory has an htdocs directory." | tok domainDir | tok _ aRequest host findTokens: '.'. domainDir _ tok size > 1 ifTrue: [tok at: tok size - 1] ifFalse: [tok at: tok size]. ^ '/home/' , domainDir , '/htdocs' I am using a Comanche/Seaside interface very similar to IAKom, and thus the #process: method knows the request argument, which in turn is passed into the method above. In this way, a web URL of, say, http://www.smalltalkpro.com will result in a document root of "/home/smalltalkpro/htdocs", and a web URL of http://www.bountifulbaby.com will result in a document root of "/home/bountifulbaby/htdocs". Now on to the next thing: I absolutely *must* be able to support allowing a Graphics Design person to use Dreamweaver to generate the html pages. If I don't do this, I lose a big chunk of my propoganda machine, because that is the strategy they are using at work. Fortunately, my son knows (and likes) Dreamweaver. Thus, all of the bountifulbaby.com pages were created with Dreamweaver. However, the requirement of using Dreamweaver for the html code severely limits my ability to use the html templating scheme that Seaside uses. Now look at the "Past Work" page at: http://www.bountifulbaby.com/pastwork.ssp. This page was originally a "pastwork.html" static page created via Dreamweaver, but it is now a dynamic page that looks in a "pastwork" directory (under the doc root) for any jpg images in that directory, and serves those images. It gives each picture the baby name of the jpg filename that it found. Thus, to add to the list of babies on this page, all that Adam (or my wife, Denise) must do is drop the picture in the "pastwork" directory, and it is automatically served on this page. OK, but how exactly was that done? Our "IAKom" class (well, actually we've called it something else, and left the original IAKom intact) has the following #process: method: process: aRequest "This is the required Comanche method that kicks everything off. Nothing else works until this method is properly run, and it will automatically be run by Comanche." | str | str _ self processStaticPage: aRequest. str notNil ifTrue: [^ str]. ^ self processSeasidePage: aRequest The #processSeasidePage: is essentially the same as the original IAKom #process: method, but with a minor mod where we hardwired it to the "seaside" URL. Look at, for example, http://www.bountifulbaby.com/seaside/calc to see it in action, or any of the other example Seaside apps (minesweeper, whatever). You'll see 'em work. But for the SSP side of things, the relevant portion of #processStaticPage: that handles the SSP stuff is this: (file name endsWith: 'ssp') ifTrue: [str _ HTMLformatter evalEmbedded: file contents with: httpRequest] ifFalse: [str _ file contents] Notice in this code snippet that the file being served by our custom "IAKom " (in the #processStaticPage: method) is checked to see if it ends in "ssp", and if it does, it passes it to the HTMLformatter (the same one that PWS uses for SSP) to process the SSP code. Thus, to make the "pastwork.ssp" page work, Adam stripped out the html from his Dreamweaver code that generated the pictures, and replaced it with a single SSP call to a method we wrote together that walked the "pastwork" directory as described. We in turn stole his html from the original "pastwork.html" page and used it as a "guide" for the new method, so it's not like his original html was wasted work. OK, so far, so good. But, there's no real Seaside involvement yet (besides the standard example Seaside apps that nobody really knows about that visits the site). So, what's next? I want to use Seaside, but you can see we haven't really used it yet. But I plan to as we move forward. One thing we need is a clean way to grab modified Dreamweaver html and use it in a Seaside app. Some minor manual modifications (edits) to the html are OK, but we need to keep the required editing down to a minimum. If we have to extensively hack the Dreamweaver html to make it work, we lose our propoganda effect. Yes, I realize I can use IAFileTemplate to have a file-based template, and have it load in the Dreamweaver html, and this is actually a good start. But, one of the immediate problems hit is how to serve the static content found in the Dreamweaver html-- JPG and GIF images, for example. We don't want to have to code an absolute path for these static images. Absolute paths suck-- what if you want to host the site somewhere else? This limitation would also be jumped on by the hounds at work. We also don't want to have to write a bunch of bogus action methods in our Seaside IAApplication subclass to serve the images dynamically. We need true static content serving from a standard Dreamweaver html file well-integrated into a Seaside app. This bugs me. What I am thinking of doing right now is intercepting the static file requests in our "IAKom" class, and munging the path to remove the "/seaside/app/5/top/1/view" stuff from the URL so that our custom IAKom class can serve it before it gets to the Seaside app. That way static resources (images and pictures) can be served before it gets to the Seaside side of things. But I don't see a clean way of doing this when the Seaside app served the original html that referenced the static resources. The only way I see (off hand) is by having my "IAKom" class detect the static resource in the URL, and then munge the URL to make it look purely static for Comanche. But then, I'm not exactly a world-class pro with Squeak, Comanche, or Seaside right now, so we're both learning the tools. I'm primarily a VisualWorks person. The reason for grabbing these tools was also part of my propoganda machine-- the gig I'm at now thinks they want a purely open-source solution, without tying to any vendor, and they haven't figured out yet that Java is not open source and ties them squarely to Sun. That's actually addressed by my propoganda machine via the rhetoric at the bottom of my home page at: http://www.smalltalkpro.com. Management at my current gig has made a big-deal about not tying to any vendor, and yet simultaneously selected Java to develop with. They don't realize what they've done (how those two statements are so mutually exclusive), but when they do realize it, I want a strong example available using purely open source tools. It's all part of the propoganda machine. And, my wife is actually making money with her site, too. So, no matter what the outcome of the propoganda machine, it's still a win for us. And, as a propoganda machine, we are further along (i.e., we have more functionality) than the Java team has at work. And, I'm confident we can keep it that way. Anyway, you can see what we are up to. Any suggestions along these lines, to help fascilitate our goals, would surely be considered, and appreciated. Nevin From nevin@smalltalkpro.com Sun Apr 21 04:20:01 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Sat, 20 Apr 2002 21:20:01 -0600 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204201631500.1405-100000@cable.beta4.com> <3CC229B0.2070401@smalltalkpro.com> Message-ID: <3CC22FE0.7000106@smalltalkpro.com> Nevin Pratt wrote: > > One thing we need is a clean way to grab modified Dreamweaver html and > use it in a Seaside app. Some minor manual modifications (edits) to > the html are OK, but we need to keep the required editing down to a > minimum. If we have to extensively hack the Dreamweaver html to make > it work, we lose our propoganda effect. > I might also add, stripping html out of the Dreamweaver output, and replacing it with a single line of SSP (Smalltalk) code, and then reusing the stripped out html in the Smalltalk image, fits very well within the guidelines required by my propoganda machine. As long as it is very easy for the Smalltalk programmer to take the Graphic's design produced by the Graphic Artist (who will be using Dreamweaver primarily), and plug it into the backend, then it passes. The point is that the hounds at work think that a programmer should *not* be doing the graphic layout of the web pages, but that should instead be done by a graphic artist (one with rudimentary, or very basic, html knowledge). And, I think that is actually a very worthy goal (that is exactly why NeXTSTEP was always so pretty, in my opinion, because Steve Jobs had the same opinion that a graphic artist should do the UI). The Java hounds at work are also using a high-overhead "Big Design Up Front" approach, and requiring a 10 inch stack of documentation to do anything. That will also help to make it easy for Adam to keep ahead of them. Nevin From frank@canyon-medical.com Sun Apr 21 05:55:31 2002 From: frank@canyon-medical.com (Frank Sergeant) Date: Sat, 20 Apr 2002 22:55:31 -0600 Subject: [Seaside] state of the aubergine Message-ID: <200204210354.g3L3s9LA012164@mail3.centurytel.net> Avi Bryant <avi@beta4.com> wrote: > We're currently finishing up a Seaside application that manages ticket > sales for a group of theatres - basically a point of sale app, which has ... Thank you for describing your application. > processes are quite sequential, there ended up being essentially no > coupling between the various pages. Instead, the application is > structured as a bunch of dialogs with simple inputs and simple outputs I think that is one of the major appeals of the Seaside approach, that one might avoid becoming too deeply intangled in the html flow control (if I've understood correctly). I had played a little with the app that was finally done in Dolphin by trying out Python with its httpd server and I was favorably impressed with it in many ways, although I did find myself becoming a little too intangled in coding the next actions on each page. The main reason I abandoned that approach at the time was fear that the users would not accept a web-based interface (they had been used to a DOS/Clipper interface), especially with regard to keystroke shortcuts for moving incrementally and/or rapidly through picklists. With a web-based app, I had trouble getting certain keystrokes, I forget which now, which had become "standard" in the DOS version of the app. Now I am not quite so worried about that aspect. I still wonder how well it would be received by users who are focused on data entry speed and who prefer never to move from the keyboard to the mouse. > I'll be using Seaside for some other stuff this summer, but I probably > shouldn't talk about it yet ;-). Sure, no rush, just tell us whatever you like whenever you can. (And, thanks to Nevin for posting details on how he is using Squeak and Seaside.) -- Frank From avi@beta4.com Sun Apr 21 04:59:47 2002 From: avi@beta4.com (Avi Bryant) Date: Sat, 20 Apr 2002 20:59:47 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC229B0.2070401@smalltalkpro.com> Message-ID: <Pine.LNX.4.30.0204202040310.2051-100000@cable.beta4.com> On Sat, 20 Apr 2002, Nevin Pratt wrote: > First, we *have* to be able to support virtual hosts (the gig at work > likewise does). Thus, if you check the IP for "smalltalkpro.com" as > well as "bountifulbaby.com", you will see they both point to the same > machine--my server machine. The squeak server therefore must be able to > synthesize a different "document Root" based on the incoming URL. Hmm, haven't really thought much about virtual hosts with Seaside - no document roots to worry about, and my first thought would be to just redirect to the appropiate app, so http://foo.com would get redirected (by apache or whatever) to http://foo.com/seaside/foo. But obviously this is an issue when using Comanche for static content. > However, the requirement of using Dreamweaver for the html > code severely limits my ability to use the html templating scheme that > Seaside uses. This is very interesting, since of course one of the main requirements for that templating scheme was precisely that it work well with Dreamweaver. More below. > Yes, I realize I can use IAFileTemplate to have a file-based template, > and have it load in the Dreamweaver html, and this is actually a good > start. But, one of the immediate problems hit is how to serve the > static content found in the Dreamweaver html-- JPG and GIF images, for > example. We don't want to have to code an absolute path for these > static images. Absolute paths suck-- what if you want to host the site > somewhere else? This limitation would also be jumped on by the hounds > at work. So, I think the issue here is that the defaults for the <img> tag used to suck. It used to be that <img src="@foo"> would create a path binding, that is, would look for a method named #foo and use the result of that as the src attribute (appended to the configurable "document root", which should maybe be renamed to something like "url prefix", of the app). What it does now is uses a literal binding by default, so if your app is configured to have a doc root of http://smalltalkpro.com/images, then <img src="@foo.jpg"> will become <img src="http://smalltalkpro.com/images/foo.jpg">. Notice that this allows images to be served statically (likely even by a different webserver), without requiring hardcoded paths, or any funny business with IAKom. If you want this to be chosen dynamically (like your example of iterating over all the images in a directory), add an explicit binding to #resource, ie, addBindingsTo: template (template elementNamed: 'myImage') set: #resource toPath: 'currentImage' I'm not sure exactly when this change occured, but if you grab the latest source off SSVS it'll have it. Now, I would like to see a better way of handling resources (so that, for example, dynamically generated images from within squeak become easier), and am open to suggestions for how this should work. But does that solve your immediate issues with using Dreamweaver? From nevin@smalltalkpro.com Sun Apr 21 05:12:18 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Sat, 20 Apr 2002 22:12:18 -0600 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204202040310.2051-100000@cable.beta4.com> Message-ID: <3CC23C22.7060700@smalltalkpro.com> Avi Bryant wrote: >I'm not sure exactly when this change occured, but if you grab the latest >source off SSVS it'll have it. > What/where is SSVS? When I grabbed Seaside, I grabbed it from: http://beta4.com/seaside (the "seaside-0.92.cs" link on that page). I did that about a month ago. > > > >Now, I would like to see a better way of handling resources (so that, for >example, dynamically generated images from within squeak become easier), >and am open to suggestions for how this should work. But does that solve >your immediate issues with using Dreamweaver? > > That sounds very good--like it will work for what I need. I'll probably have time Sunday evening to grab the latest source and try it and see. Thanks, Nevin From julian@beta4.com Sun Apr 21 06:09:06 2002 From: julian@beta4.com (Julian Fitzell) Date: Sat, 20 Apr 2002 22:09:06 -0700 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204202040310.2051-100000@cable.beta4.com> <3CC23C22.7060700@smalltalkpro.com> Message-ID: <3CC24972.3030503@beta4.com> Nevin Pratt wrote: > Avi Bryant wrote: > >> I'm not sure exactly when this change occured, but if you grab the latest >> source off SSVS it'll have it. >> > > What/where is SSVS? SSVS is what we developed for use as version control. More info here: http://swiki.squeakfoundation.org/sea/3 Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From julian@beta4.com Sun Apr 21 06:13:24 2002 From: julian@beta4.com (Julian Fitzell) Date: Sat, 20 Apr 2002 22:13:24 -0700 Subject: [Seaside] state of the aubergine References: <200204210354.g3L3s9LA012164@mail3.centurytel.net> Message-ID: <3CC24A74.1000507@beta4.com> Frank Sergeant wrote: > Avi Bryant <avi@beta4.com> wrote: > > >>We're currently finishing up a Seaside application that manages ticket >>sales for a group of theatres - basically a point of sale app, which has > > ... > > Thank you for describing your application. > > >>processes are quite sequential, there ended up being essentially no >>coupling between the various pages. Instead, the application is >>structured as a bunch of dialogs with simple inputs and simple outputs > > > I think that is one of the major appeals of the Seaside approach, that > one might avoid becoming too deeply intangled in the html flow control > (if I've understood correctly). I had played a little with the app that > was finally done in Dolphin by trying out Python with its httpd server > and I was favorably impressed with it in many ways, although I did find > myself becoming a little too intangled in coding the next actions on > each page. The main reason I abandoned that approach at the time was > fear that the users would not accept a web-based interface (they had > been used to a DOS/Clipper interface), especially with regard to > keystroke shortcuts for moving incrementally and/or rapidly through > picklists. With a web-based app, I had trouble getting certain > keystrokes, I forget which now, which had become "standard" in the DOS > version of the app. Now I am not quite so worried about that aspect. I > still wonder how well it would be received by users who are focused on > data entry speed and who prefer never to move from the keyboard to the > mouse. Yes, this was a concern for us as well. I think in this case that the task is sufficiently distant from direct data entry that it will be manageable. Page load times are pretty fast too considering that the server will be dedicated to the task and on the same LAN. We are confident that for most users the useability improvemnts over the existing solution will save time easily in the long run but there is one user who made heavy use of shortcut keys and it remains to be seen whether he is totally satisfied with the web-based system. He seemed ok with it in initial tests... Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From kamk@volny.cz Sun Apr 21 21:09:01 2002 From: kamk@volny.cz (Kamil Kukura) Date: Sun, 21 Apr 2002 22:09:01 +0200 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204201631500.1405-100000@cable.beta4.com> Message-ID: <3CC31C5D.4050905@volny.cz> I am developing a web application for real estate agents. It is purposed as meeting point for the agents where they would have prepared advertisements from various sources. They would have a system for managing their own informations that would be private to them or to their companies. I am using PostgreSQL for storage but no object-relation mapping. I am quite new to smalltalk and OODB systems I know only from web pages. The database (object or relation) support in Squeak is quite primitive. I feel some simple generic layer for implementing database drivers is really missing. May be me need to study object-to-relation techniques little bit. Anyway, the project si so lagged that perhaps investor will have enough and tells me good bye. And yes, I am in Czech Republic and I can live fairly good with $100 a week. In my opinion Seaside is winning when it comes to really advanced web applications. -- Kamil From avi@beta4.com Sun Apr 21 21:23:18 2002 From: avi@beta4.com (Avi Bryant) Date: Sun, 21 Apr 2002 13:23:18 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC31C5D.4050905@volny.cz> Message-ID: <Pine.LNX.4.30.0204211320000.2051-100000@cable.beta4.com> On Sun, 21 Apr 2002, Kamil Kukura wrote: > The database (object or relation) support in Squeak is quite > primitive. I feel some simple generic layer for implementing database > drivers is really missing. Yes, what I've done instead is stolen an existing generic layer. I keep a small java app running that accepts socket connections from squeak and forwards database queries through JDBC drivers; this lets me generically access Oracle, Postgres, etc, at a slight performance penalty. A pure squeak solution would be preferable, of course. From nevin@smalltalkpro.com Mon Apr 22 05:29:07 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Sun, 21 Apr 2002 22:29:07 -0600 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204202040310.2051-100000@cable.beta4.com> Message-ID: <3CC39193.7000300@smalltalk.org> Avi Bryant wrote: >So, I think the issue here is that the defaults for the <img> tag used to >suck. It used to be that <img src="@foo"> would create a path binding, >that is, would look for a method named #foo and use the result of that as >the src attribute (appended to the configurable "document root", which >should maybe be renamed to something like "url prefix", of the app). > >What it does now is uses a literal binding by default, so if your app is >configured to have a doc root of http://smalltalkpro.com/images, then ><img src="@foo.jpg"> will become ><img src="http://smalltalkpro.com/images/foo.jpg">. Notice that this >allows images to be served statically (likely even by a different >webserver), without requiring hardcoded paths, or any funny business with >IAKom. > > OK, I did the following: 1. Grabbed a "virgin" 3.2gamma image. 2. Made sure the image had all the latest 3.2gamma updates by selecting "load code updates" from the "Squeak" tab. It loaded and installed exactly one additional 3.2gamma update, for whatever that's worth. 3. Filed in 'kom49-base.11May354.cs' (the Comanche filein-- is there a newer one?) 4. Downloaded and filed in 'SSVS.cs'. 5. Evaluated the following: (SSVS forModule: 'seabed') update. (SSVS forModule: 'seaside') update. 6. Created an IAPastWork subclass of IAComponent. 7. Gave IAPastWork an #html instance method that returned a string. 8. Copied the html output from my son's old (static) 'pastwork.html' file he created with Dreamweaver to the #html method of the new IAPastWork class. 9. Defined a 'pastwork' seaside application to use the new IAPastWork component. 10. Started up an IAKom session on port 80. (for the following, note that my test machine is known on my internal network as 'test.com' or ' www.test.com') 11. Hit the following URL from my (Mozilla on Linux) browser: http://www.test.com/seaside/pastwork It did not work. It did not display the static files referenced in the 'pastwork.html' code placed in the #html method. However, it displayed all of the rest of the html code. It just did not display the images. In contrast, referencing the same html code using only Comanche, without Seaside, works fine: http://www.test.com/pastwork.html , so yes, all of the images are in place. Likewise, loading the 'pastwork.html' file directly into the browser again works just fine. So again, yes, all of the images are in place. But, trying to use the same html code in an #html method of a seaside app just doesn't work. The static images never get served. Hopefully in a day or two I'll have more time to track down *why* it did not work. But in any case, I still don't see an easy way to use Dreamweaver html in a Seaside app. Nevin From avi@beta4.com Mon Apr 22 05:45:14 2002 From: avi@beta4.com (Avi Bryant) Date: Sun, 21 Apr 2002 21:45:14 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC39193.7000300@smalltalk.org> Message-ID: <Pine.LNX.4.30.0204212135380.11858-100000@cable.beta4.com> On Sun, 21 Apr 2002, Nevin Pratt wrote: > 8. Copied the html output from my son's old (static) 'pastwork.html' > file he created with Dreamweaver to the #html method of the new > IAPastWork class. > 9. Defined a 'pastwork' seaside application to use the new IAPastWork > component. > 10. Started up an IAKom session on port 80. > (for the following, note that my test machine is known on my internal > network as 'test.com' or ' www.test.com') > 11. Hit the following URL from my (Mozilla on Linux) browser: > http://www.test.com/seaside/pastwork Ok, if you have relative urls for those images, they're not going to work *quite* that simply - obviously if your url is http://www.test.com/seaside/pastword/some/other/stuff, and you have <img src="foo.gif">, that's not going to come out as http://test.com/foo.gif the way you want it to. You need to let Seaside modify that url, which means putting an @ sign in there, like this: <img src="@foo.gif">. Hopefully that's an acceptable change to make. You'll also need to tell the Seaside app where your images are stored (eg, http://test.com/), so go into the configuration page for your pastwork app and set the document root to that url (or just '/' should work here). Programmtically, that's (IAApplication at: 'pastwork') documentRoot: '/'. This make sense? Avi From kamk@volny.cz Mon Apr 22 19:07:38 2002 From: kamk@volny.cz (Kamil Kukura) Date: Mon, 22 Apr 2002 20:07:38 +0200 Subject: [Seaside] accessing a database References: <Pine.LNX.4.30.0204211320000.2051-100000@cable.beta4.com> Message-ID: <3CC4516A.3010800@volny.cz> > > >Yes, what I've done instead is stolen an existing generic layer. I keep a >small java app running that accepts socket connections from squeak and >forwards database queries through JDBC drivers; this lets me generically >access Oracle, Postgres, etc, at a slight performance penalty. > Yea I was thinking about that. JDBC is quite nice, but it lives only with that big fat toad called Java. I am examining the combination of Ruby + DBI/DBD + SOAP. -- Kamil From kamk@volny.cz Mon Apr 22 19:22:35 2002 From: kamk@volny.cz (Kamil Kukura) Date: Mon, 22 Apr 2002 20:22:35 +0200 Subject: [Seaside] state of the aubergine Message-ID: <3CC454EB.1000607@volny.cz> It is likely to expect that seaside will be explored by developers already experienced with writing ASP or PHP server pages. For me the first touch was quite okay except the understanding of sessions. In web development area, session is usually known as some kind of storage that persists for the time a user is browsing the site and expires on inactivity. So when I saw in IAApplication the parameter "sessionLimit" I was suddenly confused. It somehow couldn't fit into my view that session doesn't expire. -- Kamil From avi@beta4.com Mon Apr 22 19:50:49 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 11:50:49 -0700 (PDT) Subject: [Seaside] accessing a database In-Reply-To: <3CC4516A.3010800@volny.cz> Message-ID: <Pine.LNX.4.30.0204221147520.12600-100000@cable.beta4.com> On Mon, 22 Apr 2002, Kamil Kukura wrote: > Yea I was thinking about that. JDBC is quite nice, but it lives only > with that big fat toad called Java. I am examining the combination of > Ruby + DBI/DBD + SOAP. I imagine you'll find SOAP too slow; my initial JDBC bridge used XML-RPC but the performance was pretty bad for large result sets, so I switched to a simple binary protocol. But, yeah, Ruby-DBI is a nice way to go (hmmm... random thoughts of producing a Ruby Plugin for Squeak...) From avi@beta4.com Mon Apr 22 19:52:32 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 11:52:32 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC454EB.1000607@volny.cz> Message-ID: <Pine.LNX.4.30.0204221151180.12600-100000@cable.beta4.com> On Mon, 22 Apr 2002, Kamil Kukura wrote: > It is likely to expect that seaside will be explored by developers > already experienced with writing ASP or PHP server pages. For me the > first touch was quite okay except the understanding of sessions. In web > development area, session is usually known as some kind of storage that > persists for the time a user is browsing the site and expires on > inactivity. So when I saw in IAApplication the parameter "sessionLimit" > I was suddenly confused. It somehow couldn't fit into my view that > session doesn't expire. Can you explain further? Sessions do expire, it's just that by default they expire in according to an LRU policy. For some situations a time-based policy might be better, and it would be simple to implement a subclass of IACache that did this. From kamk@volny.cz Mon Apr 22 21:00:07 2002 From: kamk@volny.cz (Kamil Kukura) Date: Mon, 22 Apr 2002 22:00:07 +0200 Subject: [Seaside] state of the aubergine References: <Pine.LNX.4.30.0204221151180.12600-100000@cable.beta4.com> Message-ID: <3CC46BC7.9060203@volny.cz> > > >Can you explain further? Sessions do expire, it's just that by default >they expire in according to an LRU policy. For some situations a >time-based policy might be better, and it would be simple to implement a >subclass of IACache that did this. > Well, set the sessionLimit to 20. When there are 20 users using the application, what happens when 21st user comes? -- Kamil From kamk@volny.cz Mon Apr 22 21:08:09 2002 From: kamk@volny.cz (Kamil Kukura) Date: Mon, 22 Apr 2002 22:08:09 +0200 Subject: [Seaside] accessing a database References: <Pine.LNX.4.30.0204221147520.12600-100000@cable.beta4.com> Message-ID: <3CC46DA9.3060004@volny.cz> > > >I imagine you'll find SOAP too slow; my initial JDBC bridge used XML-RPC >but the performance was pretty bad for large result sets, so I switched to >a simple binary protocol. But, yeah, Ruby-DBI is a nice way to go >(hmmm... random thoughts of producing a Ruby Plugin for Squeak...) > Wow. At first maybe calling druby (distributed ruby) from Squeak could be cool. I'm quite tempted by that idea... -- Kamil From avi@beta4.com Mon Apr 22 21:17:04 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 13:17:04 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC46BC7.9060203@volny.cz> Message-ID: <Pine.LNX.4.30.0204221313200.12600-100000@cable.beta4.com> On Mon, 22 Apr 2002, Kamil Kukura wrote: > Well, set the sessionLimit to 20. When there are 20 users using the > application, what happens when 21st user comes? Yup. The default cache works best when you have a fairly steady usage pattern. A time-expired cache would make a lot of sense when you usually only had a few users but occasionally got waves of many more. I'll add one. From cg@cdegroot.com Mon Apr 22 22:17:36 2002 From: cg@cdegroot.com (Cees de Groot) Date: 22 Apr 2002 23:17:36 +0200 Subject: [Seaside] state of the aubergine References: <3CC31C5D.4050905@volny.cz> <Pine.LNX.4.30.0204211320000.2051-100000@cable.beta4.com> Message-ID: <aa1ulg$7m5$1@home.cdegroot.com> Avi Bryant <avi@beta4.com> said: >Yes, what I've done instead is stolen an existing generic layer. I keep a >small java app running that accepts socket connections from squeak and >forwards database queries through JDBC drivers; this lets me generically >access Oracle, Postgres, etc, at a slight performance penalty. > >A pure squeak solution would be preferable, of course. > I think that you should be able to access PostgreSQL and MySQL from Squeak (IIRC, there's a Squeak driver for MySQL and the VW PostgreSQL driver has been ported). Both are probably direct socket interfaces. Oracle and Sybase would probably be relatively easy as well with FFI. -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B From julian@beta4.com Mon Apr 22 23:12:38 2002 From: julian@beta4.com (Julian Fitzell) Date: Mon, 22 Apr 2002 15:12:38 -0700 Subject: [Seaside] state of the aubergine References: <3CC31C5D.4050905@volny.cz> <Pine.LNX.4.30.0204211320000.2051-100000@cable.beta4.com> <aa1ulg$7m5$1@home.cdegroot.com> Message-ID: <3CC48AD6.8060909@beta4.com> Cees de Groot wrote: > Avi Bryant <avi@beta4.com> said: > >>Yes, what I've done instead is stolen an existing generic layer. I keep a >>small java app running that accepts socket connections from squeak and >>forwards database queries through JDBC drivers; this lets me generically >>access Oracle, Postgres, etc, at a slight performance penalty. >> >>A pure squeak solution would be preferable, of course. >> > > I think that you should be able to access PostgreSQL and MySQL from Squeak > (IIRC, there's a Squeak driver for MySQL and the VW PostgreSQL driver has been > ported). Both are probably direct socket interfaces. > > Oracle and Sybase would probably be relatively easy as well with FFI. You can access them but there is no db-independant layer. We've got around this by abstracting some stuff ourselves but in a case where you're writing something that is going to be re-used for multiple projects and the dbms' involved cannot be predicted, having a generic DBI layer is more than a nicety. Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From cg@cdegroot.com Mon Apr 22 23:36:51 2002 From: cg@cdegroot.com (Cees de Groot) Date: 23 Apr 2002 00:36:51 +0200 Subject: [Seaside] state of the aubergine References: <3CC31C5D.4050905@volny.cz> <3CC48AD6.8060909@beta4.com> Message-ID: <aa23a3$29n$1@home.cdegroot.com> Julian Fitzell <julian@beta4.com> said: >You can access them but there is no db-independant layer. We've got >around this by abstracting some stuff ourselves but in a case where >you're writing something that is going to be re-used for multiple >projects and the dbms' involved cannot be predicted, having a generic >DBI layer is more than a nicety. > So start growing one. Last time I did this I just started out with a db-dependent layer until the request for the first port came. That request hurt a bit, the subsequent requests hurt a lot less. Certainly I wouldn't take the absence of a db-independent layer as a reason to let Java enter the picture ;-). (I'm a bit on my home turf here, having designed and implemented lots of ODBC and JDBC and even ODBC-to-JDBC-bridging stuff - JDBC and ODBC suck to a large extent, because Microsoft bloated ODBC beyond recognition and JDBC imitated that; the original X/Open SAG/CLI spec would probably be a reasonable starting point for a database independence layer. I'm not sure whether it floats on the Net somewhere; an old DB/2 programming manual would probably do, IBM used to stick close to this spec). -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B From jeffo@esprithealth.com Tue Apr 23 00:00:55 2002 From: jeffo@esprithealth.com (Jeffrey Odell) Date: Mon, 22 Apr 2002 19:00:55 -0400 Subject: [Seaside] Ports of Seaside - are there useful modules Message-ID: <000701c1ea51$8f6fe490$6601a8c0@frostbite> This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C1EA30.085E4490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It seems that the unique session management concept of Seaside depends on continuations. If your favorite Smalltalk doesn't have them, porting is inhibited. Having said that, how modular is Seaside? Are there other subsystems of Seaside worth porting to other Smalltalks that are useful on their own right? Or is the essential value lost without continuations? jlo Jeffrey Odell Email: jeffo@odellsoft.com Phone: 813.335.6966 http://www.odellsoft.com <http://www.odellsoft.com/> ------=_NextPart_000_0008_01C1EA30.085E4490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <TITLE>Message

http://www.odellsoft.com

------=_NextPart_000_0008_01C1EA30.085E4490-- From Fritsche.Markus@gmx.net Tue Apr 23 00:42:18 2002 From: Fritsche.Markus@gmx.net (Markus Fritsche) Date: Tue, 23 Apr 2002 01:42:18 +0200 Subject: [Seaside] state of the aubergine In-Reply-To: References: Message-ID: <16znQx-7kb-00@router.mfritsche.dyndns.org> I thought some time if I should post this message. Why? Because I haven't= got=20 the time to help you with the things I mention...=20 > I'm asking all of this because currently, development on Seaside is alm= ost > exclusively motivated by the needs of my projects, which may or may not > have any bearing on the needs of others. I encourage y'all to speak ou= t > so that this can change. > Email me privately or respond to the list, but I'd like to hear from yo= u. I went through the tutorials, too. Although I'm thinking I can't get used= to=20 the "squeak-philosophy", seaside is very interesting and I'm thinking how= I=20 could use it to enrich my homepage with some "active sugar", like a=20 calculator for my worktime :-) I need to learn more about OODBMS (like goods :-) to think about how and = when=20 to use them (I feel a bit unconfortable about storing things in RAM -=20 especially without an USV); at this point, if I use seaside for data-base= d=20 applications, I would use mysql or postgresql (having the ability to use = the=20 data with a lot of other applications and programming languages) as DBMS=20 (just my opinion). I think it would be useful to have all classes inline-documented; as I'm = new=20 to squeak and additionally, never saw something like servlets before - ju= st=20 php - I don't know "what's for what". Also, a short text like "a short=20 journey to the seaside: exploring the code" would be nice (I think) to=20 explain the programming newbies how they should start to understand what'= s=20 going on, and how they could use it for themselves or to improve the=20 framework. But, as we all know: so many ideas and so little time... :-) Regards, Markus From avi@beta4.com Tue Apr 23 00:46:39 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 16:46:39 -0700 (PDT) Subject: [Seaside] Ports of Seaside - are there useful modules In-Reply-To: <000701c1ea51$8f6fe490$6601a8c0@frostbite> Message-ID: On Mon, 22 Apr 2002, Jeffrey Odell wrote: > It seems that the unique session management concept of Seaside depends > on continuations. If your favorite Smalltalk doesn't have them, porting > is inhibited. > > Having said that, how modular is Seaside? Are there other subsystems of > Seaside worth porting to other Smalltalks that are useful on their own > right? Or is the essential value lost without continuations? Well, Seaside is roughly based on the design of WebObjects, which doesn't use continuations; the templates and bindings system, the subcomponent model, the basic session management, etc, would all work without them: basically you would have to lose the callPage: primitive, but you'd still have jumpToPage:, and you can do a lot with that. It's still a lot nicer than, say, SSP. However, I'd say that continuations make up about half of the advantage of Seaside; that is, Seaside + continuations is, IMHO, about as much nicer to work in than WebObjects, as WebObjects is nicer to work in than JSP & co. So there'd have to be a pretty compelling reason for me to work in a Smalltalk without them - the choice of Squeak or VW meets my needs pretty well. Does anyone know if continuations can be implemented in VisualAge, anyway? I believe it has thisContext and #swapSender:, does it not? I can post a small TestCase for them if anyone wants to try. Cheers, Avi From avi@beta4.com Tue Apr 23 00:56:02 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 16:56:02 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <16znQx-7kb-00@router.mfritsche.dyndns.org> Message-ID: On Tue, 23 Apr 2002, Markus Fritsche wrote: > I think it would be useful to have all classes inline-documented; as I'm new > to squeak and additionally, never saw something like servlets before - just > php - I don't know "what's for what". Did you read the class comments? Method comments would be nice too, of course. > Also, a short text like "a short > journey to the seaside: exploring the code" would be nice (I think) to > explain the programming newbies how they should start to understand what's > going on, and how they could use it for themselves or to improve the > framework. That's interesting. Something else to add to the list of stuff to do... Thanks, Avi From jeffo@esprithealth.com Tue Apr 23 00:52:24 2002 From: jeffo@esprithealth.com (Jeffrey Odell) Date: Mon, 22 Apr 2002 19:52:24 -0400 Subject: [Seaside] Ports of Seaside - are there useful modules In-Reply-To: Message-ID: <001901c1ea58$c1069420$6601a8c0@frostbite> I'd be happy to give it a try in VisualAge - can you post the TestCase? And, is this test case a universal case for continuation? Can I test Dolphin, SmallScript, etc. with it? My original question was prompted by the fact I have a bunch of code in Dolphin I'd like to keep there. However, I also have some VisualAge stuff that would benefit from Seaside. I really liked the tutorial, and would be happy to pursue further. jlo -----Original Message----- From: Avi Bryant [mailto:avi@beta4.com] Sent: Monday, April 22, 2002 7:47 PM To: Jeffrey Odell Cc: seaside@lists.squeakfoundation.org Subject: Re: [Seaside] Ports of Seaside - are there useful modules On Mon, 22 Apr 2002, Jeffrey Odell wrote: > It seems that the unique session management concept of Seaside depends > on continuations. If your favorite Smalltalk doesn't have them, > porting is inhibited. > > Having said that, how modular is Seaside? Are there other subsystems > of Seaside worth porting to other Smalltalks that are useful on their > own right? Or is the essential value lost without continuations? Well, Seaside is roughly based on the design of WebObjects, which doesn't use continuations; the templates and bindings system, the subcomponent model, the basic session management, etc, would all work without them: basically you would have to lose the callPage: primitive, but you'd still have jumpToPage:, and you can do a lot with that. It's still a lot nicer than, say, SSP. However, I'd say that continuations make up about half of the advantage of Seaside; that is, Seaside + continuations is, IMHO, about as much nicer to work in than WebObjects, as WebObjects is nicer to work in than JSP & co. So there'd have to be a pretty compelling reason for me to work in a Smalltalk without them - the choice of Squeak or VW meets my needs pretty well. Does anyone know if continuations can be implemented in VisualAge, anyway? I believe it has thisContext and #swapSender:, does it not? I can post a small TestCase for them if anyone wants to try. Cheers, Avi From avi@beta4.com Tue Apr 23 01:15:35 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 17:15:35 -0700 (PDT) Subject: [Seaside] Ports of Seaside - are there useful modules In-Reply-To: <001901c1ea58$c1069420$6601a8c0@frostbite> Message-ID: On Mon, 22 Apr 2002, Jeffrey Odell wrote: > I'd be happy to give it a try in VisualAge - can you post the TestCase? > And, is this test case a universal case for continuation? Can I test > Dolphin, SmallScript, etc. with it? These are the tests I use - they're pretty ad hoc, but if they don't cause any walkbacks or infinite loops you know you're doing well. And, yes, all they're testing is the semantics of callCC I want, so it should be pretty universal across dialects. Note that people that are used to continuations will think these tests are a little funny; the semantics Seaside wants are not identical to the typical implementation of call/cc. --------------------- TestCase subclass: #TestContinuations instanceVariableNames: 'tmp tmp2 ' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Methods'! !TestContinuations methodsFor: 'tests'! testSimplestCallCC |x| x := [:cc | cc value: true] callCC. self assert: x.! testSimpleCallCC |x continuation| x := [:cc | continuation := cc. false] callCC. x ifFalse: [continuation value: true]. self assert: x.! testMethodTemps |i continuation| i := 0. i := i + ([:cc | continuation := cc. 1] callCC). self assert: i ~= 3. i = 2 ifFalse: [continuation value: 2].! testBlockVars |continuation a| tmp := 0. a := [:cc | continuation := cc. 0] callCC. tmp := tmp + a. tmp2 isNil ifFalse: [tmp2 value] ifTrue: [#(1 2 3) do: [:i | [:cc | tmp2 := cc. continuation value: i] callCC]]. self assert: tmp = 6.! testBlockTemps |y| #(1 2 3) inject: 0 into: [:j :i ||x| x := i. tmp isNil ifTrue: [tmp2 := [:cc | tmp := cc. [:q]] callCC]. tmp2 value: x. x := 17]. y := [:cc | tmp value: cc. 42] callCC. self assert: y = 1.! ! ----------------------------------- > My original question was prompted by the fact I have a bunch of code in > Dolphin I'd like to keep there. However, I also have some VisualAge > stuff that would benefit from Seaside. My initial playing around with Dolphin didn't make me very optimistic about getting call/cc working - I couldn't even figure out how to get my hands on the stack. But I didn't try all that hard. > I really liked the tutorial, and would be happy to pursue further. Good luck, Avi From tim@sumeru.stanford.edu Tue Apr 23 02:21:16 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Mon, 22 Apr 2002 18:21:16 -0700 Subject: [Seaside] state of the aubergine In-Reply-To: References: Message-ID: This is what I'm looking at doing with SeaSide. At the moment I'm trying it in Stephen Pair's swikinet stuff as well, but it just dosn't seem to work with my mindset. Lots of clever stuff, but somehow it baffles me... Anyway the basic requirement is fairly simple seeming - I have to present tests consisting of multiple choice questions and record the answers. The 'teacher' has to be able to choose groups of questions from a pool and assemble them into tests. There will also be a pool of pre-built tests. Teacher must be able to add new questions, which would be 'private'. Teacher must be able to add/remove students to the permitted users. Teacher must be able to see the results of all tests for students in some reasonable format (a table I suppose) and email the form to somewhere for record keeping (CSV type file would be fine and easy). Teachers will need login ids that permit them to do al the above. Students will need login ids that permit them only to take tests. Tests will be either 'practise' or 'graded'. Tests will consist of a modest number of questions, typically twenty or so. Practise tests may be taken several times by any student and the student will see both their grade and the correct answers at the end. Graded tests can only be taken once and the student see only their result. Graded tests may have a time limit attached - 20 mins, or whatever. The timing would start when the students hits the start-test button for the first question. Once the time limit is reached there would be no more questions presented and the results would be worked out. If the student finishes before any time limit they can hit a finished-test button. Questions will (initially, there are dreams of more sophistication) consist of a text explaining the problem and a short (3-5) list of possible answers. The neat trick is that the list of answers will be re-ordered randomly each time they are presented to avoid students remembering "oh, that one was 'b' last time" so some way to remember the ordering used is needed. I'm assuming a session related var can do this. We need to maintain the appearance of many separate areas, one for each college/teacher using the service (could be several teachers from each college I supose). I don't mind how that is done, but the swikinet DNS handler does a good job of making a single server respond to many URLs. Obviously there needs to be a nice simple way to add new colleges/teachers to the system. I imagine keeping that as the preserve of the overall admin person rather than allowing teachers to do it for themselves. I managed to make a very simple testing demo in ComSwiki several months ago and then got lost in swikinet somehow. I think a part of the trouble is that it is very focussed on the swiki.net needs and digging out the infrastructure is hard work, even with Stephen trying to explain it. Of course, part of the problem is that I know a lot about the vm & low-level stuff but bugger all about writing applications. So, all advice welcomed. I need to get this done _really_ quickly, I'm a long way behind on original estimates and things are getting desperate. I'll obviously need to know how to deal with permissions, logins, cookies, sessions, aaargh! Help Obi-wan WebPerson, you're my only hope! tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- A gross ignoramus -- 144 times worse than an ordinary ignoramus. From nevin@smalltalkpro.com Tue Apr 23 02:40:17 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 19:40:17 -0600 Subject: [Seaside] state of the aubergine References: Message-ID: <3CC4BB81.1040500@smalltalkpro.com> Avi Bryant wrote: > >Ok, if you have relative urls for those images, they're not going to work >*quite* that simply - obviously if your url is >http://www.test.com/seaside/pastword/some/other/stuff, and you have >

, that's not going to come out as >http://test.com/foo.gif the way you want it to. > >You need to let Seaside modify that url, which means putting an @ sign in >there, like this:

. Hopefully that's an acceptable >change to make. > >You'll also need to tell the Seaside app where your images are stored (eg, >http://test.com/), so go into the configuration page for your pastwork app >and set the document root to that url (or just '/' should work here). >Programmtically, that's > (IAApplication at: 'pastwork') documentRoot: '/'. > >This make sense? > >Avi > Well, nobody dumps ALL of their images in just one directory. They will always be scattered among a number of subordinate directories-- not just one. Therefore, the mechanism used needs to be able to follow a path down from the docRoot. And that doesn't seem to be supported (i.e.,

won't work). I'm still inclined to change the "IAKom" code (actually, I've called it "IAComancheInterface" as to not touch the original IAKom) to hack out the seaside portion of the URL it sees when the end of the URL is ".jpg" or ".gif". After all, I can't think of anytime such a URL should *not* be statically served. Can you? For example, wouldn't you *always* want

statically served? If you wanted it dynamically served, wouldn't you instead write

, and not have the ".gif" extension? Likewise, wouldn't you *always* want

statically served? Again, if you wanted seaside to dynamically serve it, wouldn't you *always* write something like

instead? (thus ommitting not only the trailing ".gif", but also the leading "images/" portion) In other words, when using Comanche with Seaside, I would think that static images should be handled entirely by Comanche and not involve Seaside at all. But there doesn't seem to be any way to do that while simultaneously driving the html from the #html method of the seaside app, unless the Comanche/Seaside interface detects the ".jpg" or ".gif" extension and hacks out the seaside portion of the URL so that Comanche can handle it. I see the same issues if you instead use Apache with Seaside. The problem is that Seaside doesn't integrate static content very well with its way of doing things (although for purely dynamic content, Seaside seems top notch). Or at least, that's how it is all appearing to me. I'd love to be corrected, though :-) Nevin From avi@beta4.com Tue Apr 23 03:19:36 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 19:19:36 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC4BB81.1040500@smalltalkpro.com> Message-ID: On Mon, 22 Apr 2002, Nevin Pratt wrote: > Well, nobody dumps ALL of their images in just one directory. They will > always be scattered among a number of subordinate directories-- not just > one. Therefore, the mechanism used needs to be able to follow a path > down from the docRoot. And that doesn't seem to be supported (i.e., >

won't work). It won't? Have you tried it? From nevin@smalltalkpro.com Tue Apr 23 03:41:56 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 20:41:56 -0600 Subject: [Seaside] state of the aubergine References: Message-ID: <3CC4C9F4.2050807@smalltalkpro.com> Avi Bryant wrote: >On Mon, 22 Apr 2002, Nevin Pratt wrote: > >>Well, nobody dumps ALL of their images in just one directory. They will >>always be scattered among a number of subordinate directories-- not just >>one. Therefore, the mechanism used needs to be able to follow a path >>down from the docRoot. And that doesn't seem to be supported (i.e., >>

won't work). >> > >It won't? Have you tried it? > > > Yes. Assuming a

example, where the docRoot of the seaside app is set to: "http://www.test.com/", it looks like it is trying to bind to a 'foo' instance variable, because it results in a walkback with message . This is because of an attempted lookup against my IATest instance, which of course errors because there is no "foo" instance variable. But, if I instead just use

, and instead put the image path in the docRoot (i.e., change the docRoot to: "http://www.test.com/path"), then it works like you said. Nevin From nevin@smalltalkpro.com Tue Apr 23 03:49:55 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 20:49:55 -0600 Subject: [Seaside] state of the aubergine References: <3CC4C9F4.2050807@smalltalkpro.com> Message-ID: <3CC4CBD3.4030405@smalltalkpro.com> Nevin Pratt wrote: > > > But, if I instead just use

^^^^^^^^^ But again, why would I ever want a trailing ".jpg" here? If there is a trailing ".jpg" (or ".gif", for the matter), wouldn't I *always* want it statically served? And in that case, why would I want the leading "@"? Can you think of a counter-example where this idea is wrong? And if not, should we modify Seaside to behave that way? Or should I handle it at the Comanche/Seaside interface (i.e., IAKom) (i.e., hack out the seaside portion of the URL when it sees the trailing ".jpg" or ".gif" so that the URL never gets dispatched to Seaside)? What do you think? Nevin From julian@beta4.com Tue Apr 23 04:09:17 2002 From: julian@beta4.com (Julian Fitzell) Date: Mon, 22 Apr 2002 20:09:17 -0700 Subject: [Seaside] state of the aubergine References: <3CC4C9F4.2050807@smalltalkpro.com> Message-ID: <3CC4D05D.3040100@beta4.com> Nevin Pratt wrote: > Avi Bryant wrote: > >> On Mon, 22 Apr 2002, Nevin Pratt wrote: >> >>> Well, nobody dumps ALL of their images in just one directory. They will >>> always be scattered among a number of subordinate directories-- not just >>> one. Therefore, the mechanism used needs to be able to follow a path >>> down from the docRoot. And that doesn't seem to be supported (i.e., >>>

won't work). >>> >> >> It won't? Have you tried it? >> >> >> > > Yes. > > Assuming a

example, where the docRoot of the > seaside app is set to: "http://www.test.com/", it looks like it is > trying to bind to a 'foo' instance variable, because it results in a > walkback with message . This is > because of an attempted lookup against my IATest > instance, which of course errors because there is no "foo" instance > variable. > > But, if I instead just use

, and instead put the > image path in the docRoot (i.e., change the docRoot to: > "http://www.test.com/path"), then it works like you said. > > Nevin Just out of interest, does it work with

?? Obviously not a solution but it would confirm my suspicion of the problem. As for the reason to have @foo.jpg as the ID, the reason is that if I don't want to manually create a binding, I can give the id @foo.jpg which makes the element dynamic (because it has an id) and the id ("foo.jpg") is used by default as the name of the image (appended to the docRoot). If you just put

then it wouldn't get the docRoot added, and if you put

then you'd have to write a binding when the default could have sufficed. Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From nevin@smalltalkpro.com Tue Apr 23 04:48:57 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 21:48:57 -0600 Subject: [Seaside] state of the aubergine References: <3CC4C9F4.2050807@smalltalkpro.com> <3CC4D05D.3040100@beta4.com> Message-ID: <3CC4D9A9.4030801@smalltalkpro.com> Julian Fitzell wrote: > > > Just out of interest, does it work with

?? Hmm, sort of. It looks like it results in

. But IAKom>>process: explicitly looks for "/" rather than "\" (via "aRequest url findTokens: '/'"). Consequently, the URL isn't getting properly parsed for this case. So, no, it doesn't work, even though it sort of does. I think you see what I mean. In other words, to make that work would again require hacking the IAKom code. > > Obviously not a solution but it would confirm my suspicion of the > problem. > > As for the reason to have @foo.jpg as the ID, the reason is that if I > don't want to manually create a binding, I can give the id @foo.jpg > which makes the element dynamic (because it has an id) and the id > ("foo.jpg") is used by default as the name of the image (appended to > the docRoot). If you just put

then it > wouldn't get the docRoot added, and if you put

then > you'd have to write a binding when the default could have sufficed. Good point for not modifying Seaside for what I was thinking. But, if Comanche handles the static images instead of Seaside (which I'm still thinking should be the case if there is no leading "@"), it will automatically get appended to the docRoot (as Comanche understands it) anyway. Which brings me back to thinking about modifying IAKom again. But then, I think I need to think about it some more. Nevin From avi@beta4.com Tue Apr 23 05:10:20 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 21:10:20 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC4CBD3.4030405@smalltalkpro.com> Message-ID: On Mon, 22 Apr 2002, Nevin Pratt wrote: > > But, if I instead just use

> > ^^^^^^^^^ > But again, why would I ever want a trailing ".jpg" here? If there is a > trailing ".jpg" (or ".gif", for the matter), wouldn't I *always* want it > statically served? And in that case, why would I want the leading "@"? Well, by "statically served" what you mean is "have a document root prepended". The @ is what's alerting Seaside that this tag should not be output verbatim, but should be treated specially. The @ is actually just a macro that Seaside uses by default; if you have another rule that you want to encode, it's quite easy to add another macro. It sounds like you want one that takes all tags with a src attribute ending in .gif, .jpg, etc, and prepend a certain path to them. If you take a look at the Seaside-Macros category you'll see some examples to emulate. To see where they're used, look at IATemplate>>defaultExpander. > And if not, should we modify Seaside to behave that way? Or should I > handle it at the Comanche/Seaside interface (i.e., IAKom) (i.e., hack > out the seaside portion of the URL when it sees the trailing ".jpg" or > ".gif" so that the URL never gets dispatched to Seaside)? This makes me uneasy. I'd much rather see it done as a macro. Avi From avi@beta4.com Tue Apr 23 05:14:05 2002 From: avi@beta4.com (Avi Bryant) Date: Mon, 22 Apr 2002 21:14:05 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <3CC4C9F4.2050807@smalltalkpro.com> Message-ID: On Mon, 22 Apr 2002, Nevin Pratt wrote: > Assuming a

example, where the docRoot of the > seaside app is set to: "http://www.test.com/", it looks like it is > trying to bind to a 'foo' instance variable, because it results in a > walkback with message . Aha. So what's going on here is that each IAElement subclass is being asked whether they want that tag. Now, IAImage grabs tags and IARepeat grabs anything with a / in the id. What must be happening is that IARepeat is being asked first. We need to find some better way of ordering this (for example, matches on tag take precedence over matches on attributes) so these sorts of things don't happen. From nevin@smalltalkpro.com Tue Apr 23 05:44:12 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 22:44:12 -0600 Subject: [Seaside] state of the aubergine References: Message-ID: <3CC4E69C.6010209@smalltalkpro.com> Avi Bryant wrote: >On Mon, 22 Apr 2002, Nevin Pratt wrote: > >>Assuming a

example, where the docRoot of the >>seaside app is set to: "http://www.test.com/", it looks like it is >>trying to bind to a 'foo' instance variable, because it results in a >>walkback with message . >> > >Aha. So what's going on here is that each IAElement subclass is being >asked whether they want that tag. Now, IAImage grabs tags >and IARepeat grabs anything with a / in the id. What must be happening >is that IARepeat is being asked first. We need to find some better >way of ordering this (for example, matches on tag take precedence over >matches on attributes) so these sorts of things don't happen. > >_______________________________________________ > Yes, I remember seeing the IARepeat thing in the debugger. Nevin From nevin@smalltalkpro.com Tue Apr 23 05:45:23 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Mon, 22 Apr 2002 22:45:23 -0600 Subject: [Seaside] state of the aubergine References: Message-ID: <3CC4E6E3.10805@smalltalkpro.com> Avi Bryant wrote: >>And if not, should we modify Seaside to behave that way? Or should I >>handle it at the Comanche/Seaside interface (i.e., IAKom) (i.e., hack >>out the seaside portion of the URL when it sees the trailing ".jpg" or >>".gif" so that the URL never gets dispatched to Seaside)? >> > >This makes me uneasy. I'd much rather see it done as a macro. > >Avi > It makes me uneasy, too. Feels too much like a "hack". I'll see if I can wrap my brain around the macro stuff tomorrow. Nevin From julian@beta4.com Tue Apr 23 04:19:04 2002 From: julian@beta4.com (Julian Fitzell) Date: Mon, 22 Apr 2002 20:19:04 -0700 Subject: [Seaside] state of the aubergine References: Message-ID: <3CC4D2A8.1060300@beta4.com> Tim Rowledge wrote: > This is what I'm looking at doing with SeaSide. At the moment I'm trying > it in Stephen Pair's swikinet stuff as well, but it just dosn't seem to > work with my mindset. Lots of clever stuff, but somehow it baffles me... > > Anyway the basic requirement is fairly simple seeming - I have to > present tests consisting of multiple choice questions and record the > answers. > > The 'teacher' has to be able to choose groups of questions from a pool > and assemble them into tests. There will also be a pool of pre-built > tests. Teacher must be able to add new questions, which would be > 'private'. Teacher must be able to add/remove students to the permitted > users. Teacher must be able to see the results of all tests for students > in some reasonable format (a table I suppose) and email the form to > somewhere for record keeping (CSV type file would be fine and easy). > Teachers will need login ids that permit them to do al the above. > > Students will need login ids that permit them only to take tests. > > Tests will be either 'practise' or 'graded'. Tests will consist of a > modest number of questions, typically twenty or so. Practise tests may > be taken several times by any student and the student will see both > their grade and the correct answers at the end. Graded tests can only be > taken once and the student see only their result. Graded tests may have > a time limit attached - 20 mins, or whatever. The timing would start > when the students hits the start-test button for the first question. > Once the time limit is reached there would be no more questions > presented and the results would be worked out. If the student finishes > before any time limit they can hit a finished-test button. Timing should be pretty easy. You can store the start time in the session and compare it each time a question is submitted to see if the time has elapsed yet. > Questions will (initially, there are dreams of more sophistication) > consist of a text explaining the problem and a short (3-5) list of > possible answers. The neat trick is that the list of answers will be > re-ordered randomly each time they are presented to avoid students > remembering "oh, that one was 'b' last time" so some way to remember the > ordering used is needed. I'm assuming a session related var can do this. Ordering is non-issue. If you create a list of radio buttons, you give it a Collection of items. The actual item associated with the selected radio button is given to you so you can do a straight comparison. Or even just have a flag in the PossibleAnswer object that indicates whether it is correct. All depends how you implement your data objects of course. > We need to maintain the appearance of many separate areas, one for each > college/teacher using the service (could be several teachers from each > college I supose). I don't mind how that is done, but the swikinet DNS > handler does a good job of making a single server respond to many URLs. > Obviously there needs to be a nice simple way to add new > colleges/teachers to the system. I imagine keeping that as the preserve > of the overall admin person rather than allowing teachers to do it for > themselves. > > I managed to make a very simple testing demo in ComSwiki several months > ago and then got lost in swikinet somehow. I think a part of the trouble > is that it is very focussed on the swiki.net needs and digging out the > infrastructure is hard work, even with Stephen trying to explain it. Of > course, part of the problem is that I know a lot about the vm & > low-level stuff but bugger all about writing applications. > > So, all advice welcomed. I need to get this done _really_ quickly, I'm > a long way behind on original estimates and things are getting > desperate. I'll obviously need to know how to deal with permissions, > logins, cookies, sessions, aaargh! Help Obi-wan WebPerson, you're my > only hope! > > tim The most important thing is figuring out how you're storing (database, text file, ...) and representing the data (what objects you're using for it). Once you have those objects, most if not all of what you're proposing should be relatively easy. We haven't played with virtual hosts or anything in terms of different looks for essentially the same site and we haven't done much with permissions or authentication yet (only HTTP Basic at the moment) but both should be doable. I'm heading out the door but Avi may have further suggestions and I'll look over it again tomorrow to see if I have any more. Obviously you can keep posting with questions. Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From avi@beta4.com Tue Apr 23 09:53:42 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 23 Apr 2002 01:53:42 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: Message-ID: On Mon, 22 Apr 2002, Tim Rowledge wrote: > So, all advice welcomed. I need to get this done _really_ quickly, I'm > a long way behind on original estimates and things are getting > desperate. I'll obviously need to know how to deal with permissions, > logins, cookies, sessions, aaargh! Help Obi-wan WebPerson, you're my > only hope! Cookies. Heh! Sessions. Heh! A Jedi craves not these things. Help you I can. Yes, mmm. So, here's my advice. 90% of the work in this app is going to be on the actual model. For now, forget about the web and all the nonsense that goes with it. Trust that Seaside will handle this effortlessly for you when the time comes. Instead, build the logic: how are questions represented? How are they structured into tests? How do you model a particular writing of a test, and where do you record the answers? How is this data persisted? Who can access/read/write which parts of it? Take this as far as you can and still be able to test it with SUnit instead of with a live interface. At that point, we should be able to guide you very easily through the triviality of performing these same operations over the web. Now, that's not to say you shouldn't play around with the web stuff in the meantime. But there is a (usually justified) fear that the web will impose its own bizarre structures on the entire application, and that writing a web app is thus a completely different thing from writing any other code, which Seaside makes a concerted effort to prove false ("No! No different! Only different in your mind. You must unlearn what you have learned"). Ok, no more Yoda quotes. Go out and write the code, and come back when you want help with the dinky little HTML bits. And ask lots of questions when you do. I like answering questions, it saves me from having to write real documentation. Cheers, Avi From kamk@volny.cz Tue Apr 23 17:10:11 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 23 Apr 2002 18:10:11 +0200 Subject: [Seaside] escaping [ ] Message-ID: <3CC58763.4080506@volny.cz> Is it possible to escape [binding]?

...some text with [a section in square brackets] occuring in html

-- Kamil From kamk@volny.cz Tue Apr 23 17:31:45 2002 From: kamk@volny.cz (Kamil Kukura) Date: Tue, 23 Apr 2002 18:31:45 +0200 Subject: [Seaside] SAG/CLI References: <3CC31C5D.4050905@volny.cz> <3CC48AD6.8060909@beta4.com> Message-ID: <3CC58C71.7080102@volny.cz> > (I'm a bit on my home turf here, having designed and implemented lots > of ODBC > and JDBC and even ODBC-to-JDBC-bridging stuff - JDBC and ODBC suck to > a large > extent, because Microsoft bloated ODBC beyond recognition and JDBC > imitated > that; the original X/Open SAG/CLI spec would probably be a reasonable > starting point for a database independence layer. I'm not sure whether it > floats on the Net somewhere; an old DB/2 programming manual would probably > do, IBM used to stick close to this spec). Yes, I found DDJ's article about it (http://www.ddj.com/documents/s=953/ddj9613a/9613a.htm) And there is also DB2 Call Level Interface Guide and Reference (http://www-4.ibm.com/cgi-bin/software/db2www/library/document.d2w/report?&fn=sqll0.html) Because PostgreSQL connection is already there, I am looking forward when it could be wrapped as a database driver :) -- Kamil From avi@beta4.com Tue Apr 23 21:39:38 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 23 Apr 2002 13:39:38 -0700 (PDT) Subject: [Seaside] escaping [ ] In-Reply-To: <3CC58763.4080506@volny.cz> Message-ID: On Tue, 23 Apr 2002, Kamil Kukura wrote: > Is it possible to escape [binding]? > >

...some text with [a section in square brackets] occuring in html

Well, you can always use

... some text with [a section in square brackets] occuring in html

Obviously that's a little bit awkward. Suggestions for escaping syntax are welcome. From rsiler@u.washington.edu Tue Apr 23 22:42:29 2002 From: rsiler@u.washington.edu (Randy Siler) Date: Tue, 23 Apr 2002 14:42:29 -0700 Subject: [Seaside] Just read the first tutorial Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3102417750_41519391 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable And I=B9m intrigued. Looking forward to what=B9s yet to come. --=20 Randy Siler Coordinator, CIDR Computing Center for Instructional Development & Research 396 Bagley Hall, BOX 351725 VOICE: 206/543-6588 UNIVERSITY OF WASHINGTON FAX: 206/685-1213 SEATTLE, WA 98195-1725 EMAIL: siler@cidr.washington.edu=20 --B_3102417750_41519391 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Just read the first tutorial And I’m intrigued. Looking forward to what’= ;s yet to come.

--
Randy Siler           &nb= sp;   Coordinator, CIDR Computing
Center for Instructional Development & Research
396 Bagley Hall, BOX 351725         = ;      VOICE: 206/543-6588
UNIVERSITY OF WASHINGTON         &n= bsp; FAX: 206/685-1213
SEATTLE, WA 98195-1725         &nbs= p;      EMAIL: siler@cidr.washington.edu
--B_3102417750_41519391-- From rsiler@u.washington.edu Tue Apr 23 23:25:31 2002 From: rsiler@u.washington.edu (Randy Siler) Date: Tue, 23 Apr 2002 15:25:31 -0700 Subject: [Seaside] Finished the second tutorial Message-ID: > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3102420332_41667995 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Looking forward to more... --B_3102420332_41667995 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Finished the second tutorial Looking forward to more... --B_3102420332_41667995-- From avi@beta4.com Tue Apr 23 23:55:40 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 23 Apr 2002 15:55:40 -0700 (PDT) Subject: [Seaside] Finished the second tutorial In-Reply-To: Message-ID: On Tue, 23 Apr 2002, Randy Siler wrote: > Looking forward to more... Yeah, there really oughta be a third tutorial by now (explaining subcomponents through a simple calendar/todo-list). I might have time for that this weekend... In the meantime, a brief primer on subcomponents: - Any Seaside component can be embedded into the template of any other. The easiest way to do this is by inserting a tag with the name of the subcomponent and a dynamic id; for example, to embed the 'counter' example into your page, add . - callPage: and jumpToPage: from within a subcomponent will replace that subcomponent within the context of the parent page. Thus, you can embed entire applications and they'll (mostly) still work; this also allows frame-like behavior without using frames. - You can bind to the instance variables of a subcomponent. These will be synchronized with their bindings each time the component is viewed. For instance, in the above example of embedding IACounter, if you added the following binding: addBindingsTo: template (template elementNamed: 'counter') set: #count to: 42 Then the counter will stay fixed at 42. These bindings can also be bidirectional; if you have an instance variable called 'x' in your parent component, and you have addBindingsTo: template (template elementNamed: 'counter') bind: #count toPath: 'x' then the 'x' instvar in the parent will be kept in sync with the counter in the child. Be careful about when you use set:... and when you use bind:..., as you don't always want the subcomponent to be trying to push its values back to the parent. - Subcomponents can have default bindings. Implement the #defaultBindings method with a series of self bind:... statements. You can use the 'id' instvar to get the sea:id used in the template (in the above example, 'id' would be set to 'counter'). A typical #defaultBindings looks like defaultBindings self bind: #count toPath: id - Subcomponents can access their parent through the instvar 'parent', and the top-level component through 'self root'. There is a special instvar named 'container' that can be used to invoke methods on an unknown parent; messages sent to container will be forwarded to the first parent found that responds to them. This is useful for subcomponents that know they'll be used within a certain rough context, but don't want to be tightly coupled to a specific parent. - Some useful subcomponents that come with Seaside include IADateSelector, IABatch, and IAPath. There are a number more in the Seaside-Components category, most of which have examples that illustrate their use in Seaside-Examples. Seaside-Examples-Store is also good for understanding the use of subcomponents. The pattern it uses of a simple "frame" component at the toplevel, with the subcomponents doing most of the work, is one I've found particularly useful. From nevin@smalltalkpro.com Wed Apr 24 04:53:13 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Tue, 23 Apr 2002 21:53:13 -0600 Subject: [Seaside] Body tag attributes References: Message-ID: <3CC62C29.3000106@smalltalkpro.com> Hmmm, seems that if you have a tag with other attributes in the template, the other attributes are ignored. For example: This example gets changed to just a simple tag by Seaside, and the background attribute is never recognized. Nevin From avi@beta4.com Wed Apr 24 05:32:55 2002 From: avi@beta4.com (Avi Bryant) Date: Tue, 23 Apr 2002 21:32:55 -0700 (PDT) Subject: [Seaside] Body tag attributes In-Reply-To: <3CC62C29.3000106@smalltalkpro.com> Message-ID: On Tue, 23 Apr 2002, Nevin Pratt wrote: > Hmmm, seems that if you have a tag with other attributes in the > template, the other attributes are ignored. > > For example: Yeah, that's an issue with the current SSVS code (I know, first I tell you to update, then I tell you not to... ;-). We're playing some games with treating the and sections specially, and one of the side effects is that the body attributes currently get lost. It's a known bug. I should also point out that the id of the body tag is not expected to be an image path, so the use of background="@mybackgroundimage.jpg" there wouldn't work the way you're expecting anyway. This is probably also something that should be fixed. For now, the workaround is this - use a simple in your template, and do something like addBindingsTo: template (template elementNamed: 'body') set: #background to: 'http://test.com/mybackgroundimage.jpg' Far from ideal, I know. Cheers, Avi From kamk@volny.cz Wed Apr 24 10:16:38 2002 From: kamk@volny.cz (Kamil Kukura) Date: Wed, 24 Apr 2002 11:16:38 +0200 Subject: [Seaside] escaping [ ] References: Message-ID: <3CC677F6.5010306@volny.cz> > > >On Tue, 23 Apr 2002, Kamil Kukura wrote: > >>Is it possible to escape [binding]? >> >>

...some text with [a section in square brackets] occuring in html

>> >Well, you can always use >

... some text with [a section in square brackets] occuring in >html

> >Obviously that's a little bit awkward. Suggestions for escaping syntax >are welcome. > What about: '[taken as a smalltalk's string]' '<>' -- Kamil From nevin@smalltalkpro.com Wed Apr 24 17:14:34 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 10:14:34 -0600 Subject: [Seaside] Better protocol conformity References: <3CC677F6.5010306@volny.cz> Message-ID: <3CC6D9EA.1040906@smalltalkpro.com> It would be nice to get a little more protocol conformity between Comanche's "HttpRequest" class and Seaside's "IARequest" class. Likewise for the "HttpResponse" and "IAResponse" classes. For example, let's say your code wants to read the host from the request. You can get the host from an HttpRequest via request header at: 'host' However, to do the same with an "IARequest" instance, you do this: request headerAt: 'host' or possibly this... request headers at: 'host' Just adding the method #header to the IARequest class so that it is the same as the current #headers method would solve this little incompatibility. For that matter, it would be nice to completely ditch the IARequest and IAResponse classes and just use Comanche's. But, lacking that, at least get better protocol conformity between them. Nevin From nevin@smalltalkpro.com Wed Apr 24 17:18:55 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 10:18:55 -0600 Subject: [Seaside] Body tag attributes References: Message-ID: <3CC6DAEF.3080100@smalltalkpro.com> Avi Bryant wrote: > >addBindingsTo: template > (template elementNamed: 'body') > set: #background to: 'http://test.com/mybackgroundimage.jpg' > >Far from ideal, I know. > >Cheers, >Avi > >_ > For some reason, I have to put a tilde before the 'body', thus: (template elementNamed: '~body') Otherwise I get a DNU. I'll try to track down why when I have time. Nevin From avi@beta4.com Wed Apr 24 18:17:36 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 10:17:36 -0700 (PDT) Subject: [Seaside] Better protocol conformity In-Reply-To: <3CC6D9EA.1040906@smalltalkpro.com> Message-ID: On Wed, 24 Apr 2002, Nevin Pratt wrote: > For that matter, it would be nice to completely ditch the IARequest and > IAResponse classes and just use Comanche's. No. Comanche's request/response classes have different goals, and, frankly, I don't like them much. If you want to submit a patch making the protocols closer I'll consider it, but you shouldn't really be having to use IARequest and IAResponse very much anyway. From avi@beta4.com Wed Apr 24 18:21:02 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 10:21:02 -0700 (PDT) Subject: [Seaside] Body tag attributes In-Reply-To: <3CC6DAEF.3080100@smalltalkpro.com> Message-ID: On Wed, 24 Apr 2002, Nevin Pratt wrote: > For some reason, I have to put a tilde before the 'body', thus: > > (template elementNamed: '~body') Oh yes, so you do - it's intentional, actually, I just forgot about it. It's ensuring that tags like that are given implicit ids don't conflict with other tags that are given explicit ones (see IAForceDynamicExpansion>>expand:). How did you figure that out in the first place? Apologies, Avi From nevin@smalltalkpro.com Wed Apr 24 18:21:29 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 11:21:29 -0600 Subject: [Seaside] Better protocol conformity References: Message-ID: <3CC6E999.2080700@smalltalkpro.com> Avi Bryant wrote: >On Wed, 24 Apr 2002, Nevin Pratt wrote: > >>For that matter, it would be nice to completely ditch the IARequest and >>IAResponse classes and just use Comanche's. >> > >No. Comanche's request/response classes have different goals, and, >frankly, I don't like them much. If you want to submit a patch making the >protocols closer I'll consider it, but you shouldn't really be having to >use IARequest and IAResponse very much anyway. > Fair enough. I probably won't be submitting patches, though, until my experience with the framework increases, so that I can have a higher confidence level of the patch(es) being proper. Until then, I'm more inclined to just bounce the idea(s) off this list to see what the response is. Thanks. Nevin From nevin@smalltalkpro.com Wed Apr 24 18:26:48 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 11:26:48 -0600 Subject: [Seaside] Body tag attributes References: Message-ID: <3CC6EAD8.7010407@smalltalkpro.com> Avi Bryant wrote: >On Wed, 24 Apr 2002, Nevin Pratt wrote: > >>For some reason, I have to put a tilde before the 'body', thus: >> >> (template elementNamed: '~body') >> > >Oh yes, so you do - it's intentional, actually, I just forgot about it. >It's ensuring that tags like that are given implicit ids don't >conflict with other tags that are given explicit ones (see >IAForceDynamicExpansion>>expand:). > >How did you figure that out in the first place? > >Apologies, >Avi > 1. Set "walkbacks in browser: no" so that I can enter the debugger when it fails. 2. Try it and watch it fail with a DNU. 3. Enter the debugger to verify it was looking for an id of 'body' from the elements in the collection. 4. Look at all the elements in the collection it was searching, and notice the body one had an id of '~body'. Nevin From tim@sumeru.stanford.edu Wed Apr 24 18:39:59 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Wed, 24 Apr 2002 10:39:59 -0700 Subject: [Seaside] Better protocol conformity In-Reply-To: <3CC6D9EA.1040906@smalltalkpro.com> References: <3CC677F6.5010306@volny.cz> <3CC6D9EA.1040906@smalltalkpro.com> Message-ID: <6d5b4e2c4b.rowledge@goldskin.attbi.com> Nevin Pratt is claimed by the authorities to have written: > For example, let's say your code wants to read the host from the > request. You can get the host from an HttpRequest via > > request header at: 'host' > > However, to do the same with an "IARequest" instance, you do this: > > request headerAt: 'host' > or possibly this... > request headers at: 'host' I don't have any opinion on making HttpRequest & IARequest closer, but I'll certainly proclaim that #headerAt: is better than 'header at:' since it hides the implemetnation of how the header stuff is done. I really, really dislike seeing chains of trivial accessor messages - it's nothing more than a poor way of expressing foo.bar.blather C-like nonsense. Use request hostHeader, implemented as headerAt: #host', in turn implemented as headers at: name. It makes it much easier to refactor later, and you know you're going to need to refactor later; unless of course the last customer is dead. tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Always responds to "Make Money Fast" postings on the Net. From nevin@smalltalkpro.com Wed Apr 24 19:01:54 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 12:01:54 -0600 Subject: [Seaside] Better protocol conformity References: <3CC677F6.5010306@volny.cz> <3CC6D9EA.1040906@smalltalkpro.com> <6d5b4e2c4b.rowledge@goldskin.attbi.com> Message-ID: <3CC6F312.9040108@smalltalkpro.com> Tim Rowledge wrote: >Nevin Pratt is claimed by the authorities to have written: > > >>For example, let's say your code wants to read the host from the >>request. You can get the host from an HttpRequest via >> >> request header at: 'host' >> >>However, to do the same with an "IARequest" instance, you do this: >> >> request headerAt: 'host' >> or possibly this... >> request headers at: 'host' >> >I don't have any opinion on making HttpRequest & IARequest closer, but >I'll certainly proclaim that #headerAt: is better than 'header at:' >since it hides the implemetnation of how the header stuff is done. I >really, really dislike seeing chains of trivial accessor messages - it's >nothing more than a poor way of expressing foo.bar.blather C-like >nonsense. > >Use request hostHeader, implemented as headerAt: #host', in turn >implemented as headers at: name. It makes it much easier to refactor >later, and you know you're going to need to refactor later; unless >of course the last customer is dead. > >tim > Yes. That's essentially what HttpRequest does. It implements #host, which in turn is implemented as #propertyAt:, and if there is no such property, does 'self header at: '. I'm inclined to recommend that #host be added to IARequest in a similar manner, and possibly also #contentLength, #contentType, and #referer. But like I just mentioned (my last response), I'm going to refrain from making any specific recommendations for awhile longer. Perhaps I can get by just fine just the way it is now. Nevin From tim@sumeru.stanford.edu Wed Apr 24 19:16:19 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Wed, 24 Apr 2002 11:16:19 -0700 Subject: [Seaside] state of the aubergine In-Reply-To: <3CC4D2A8.1060300@beta4.com> References: <3CC4D2A8.1060300@beta4.com> Message-ID: <1caf512c4b.rowledge@goldskin.attbi.com> Julian Fitzell is claimed by the authorities to have written: > > Questions will (initially, there are dreams of more sophistication) > > consist of a text explaining the problem and a short (3-5) list of > > possible answers. The neat trick is that the list of answers will be > > re-ordered randomly each time they are presented to avoid students > > remembering "oh, that one was 'b' last time" so some way to remember the > > ordering used is needed. I'm assuming a session related var can do this. > > Ordering is non-issue. If you create a list of radio buttons, you give > it a Collection of items. The actual item associated with the selected > radio button is given to you so you can do a straight comparison. Or > even just have a flag in the PossibleAnswer object that indicates > whether it is correct. All depends how you implement your data objects > of course. Err, I'm not sure I follow you here. I'm going to be randomly permuting the list of possible answers each time the question is displayed. I had been 'returning' a,b, etc as the result chosen and worrying about how to 'remember' what permutation was relevant to each occasion (obviously for five answers there's 120 possible permutations) and de-permuting. Are you suggesting that I can 'return' the entire answer string? That would certainly save one problem but might be painful if answer were big (maybe an image?). Or is there something else? Obviously it has to be hidden from the student to stop them cheating. tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim In computer science, we stand on each other's feet. - Brian Reid From avi@beta4.com Wed Apr 24 19:32:08 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 11:32:08 -0700 (PDT) Subject: [Seaside] Better protocol conformity In-Reply-To: <3CC6F312.9040108@smalltalkpro.com> Message-ID: On Wed, 24 Apr 2002, Nevin Pratt wrote: > Yes. That's essentially what HttpRequest does. It implements #host, > which in turn is implemented as #propertyAt:, and if there is no such > property, does 'self header at: '. > > I'm inclined to recommend that #host be added to IARequest in a similar > manner, and possibly also #contentLength, #contentType, and #referer. Sounds good to me. As I said, I'd be surprised if you were directly dealing with IARequest very often (and if you were I might wonder if there were a better way of doing it). But if you find you're using those, by all means add them. From avi@beta4.com Wed Apr 24 19:41:25 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 11:41:25 -0700 (PDT) Subject: [Seaside] state of the aubergine In-Reply-To: <1caf512c4b.rowledge@goldskin.attbi.com> Message-ID: On Wed, 24 Apr 2002, Tim Rowledge wrote: > Err, I'm not sure I follow you here. I'm going to be randomly permuting > the list of possible answers each time the question is displayed. I had > been 'returning' a,b, etc as the result chosen and worrying about how to > 'remember' what permutation was relevant to each occasion (obviously for > five answers there's 120 possible permutations) and de-permuting. Are > you suggesting that I can 'return' the entire answer string? That would > certainly save one problem but might be painful if answer were big > (maybe an image?). Or is there something else? Obviously it has to be > hidden from the student to stop them cheating. Returning from what? If you mean at the HTML (or rather HTTP POST) level, forget about it. Seaside doesn't operate at the level of the query string, it operates at the level of object pointers. So if you have a series of radio buttons, what you're giving the template is a collection of Answer objects, and what it's giving you back is the Answer object that was picked. It worries about generating unique IDs in the html so that it can figure out which one was actually picked, that's not your problem. The first tutorial doesn't do a great job of making this clear, I guess. But notice that by the end of the tutorial, the radio buttons are built from an array of associations, and the 'conversion' instvar is being set to the chosen association. Your answers could similarly be associations of 'a'->'7 bananas', 'b'->'a bicycle', etc. Am I completely misinterpreting what you're saying? Or does that help? Avi From tim@sumeru.stanford.edu Wed Apr 24 19:23:51 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Wed, 24 Apr 2002 11:23:51 -0700 Subject: [Seaside] state of the aubergine In-Reply-To: References: Message-ID: In message Avi Bryant wrote: > Cookies. Heh! Sessions. Heh! A Jedi craves not these things. > Help you I can. Yes, mmm. Ah, master, grateful am I indeed. But what have you got in your pocketses? OK, I'll try to worry about the actual model for a while. It'll be a nice change instead of fighting to get a login window. I'm still convinced the UI side will be the main hassle.... tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim If it was easy, the hardware people would take care of it. From tim@sumeru.stanford.edu Wed Apr 24 19:57:37 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Wed, 24 Apr 2002 11:57:37 -0700 Subject: [Seaside] state of the aubergine In-Reply-To: References: Message-ID: <1477552c4b.rowledge@goldskin.attbi.com> In message Avi Bryant wrote: > Returning from what? > > If you mean at the HTML (or rather HTTP POST) level, forget about it. > Seaside doesn't operate at the level of the query string, it operates at > the level of object pointers. So if you have a series of radio buttons, > what you're giving the template is a collection of Answer objects, and > what it's giving you back is the Answer object that was picked. It > worries about generating unique IDs in the html so that it can figure out > which one was actually picked, that's not your problem. Oh. Gosh, that sounds useful. > > The first tutorial doesn't do a great job of making this clear, I guess. I have to admit that I haven't played with the tutorial yet. I will, promise. tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Full of wisdumb. From kamk@volny.cz Wed Apr 24 22:46:13 2002 From: kamk@volny.cz (Kamil Kukura) Date: Wed, 24 Apr 2002 23:46:13 +0200 Subject: [Seaside] Better protocol conformity References: Message-ID: <3CC727A5.5090502@volny.cz> > > >On Wed, 24 Apr 2002, Nevin Pratt wrote: > >>Yes. That's essentially what HttpRequest does. It implements #host, >>which in turn is implemented as #propertyAt:, and if there is no such >>property, does 'self header at: '. >> >>I'm inclined to recommend that #host be added to IARequest in a similar >>manner, and possibly also #contentLength, #contentType, and #referer. >> > >Sounds good to me. As I said, I'd be surprised if you were directly >dealing with IARequest very often (and if you were I might wonder if there >were a better way of doing it). But if you find you're using those, by >all means add them. > I guess I need to manipulate with IAResponse. I need to set content-type to text/html with: charset="iso-8859-2". Where is the best place to do it? -- Kamil From nevin@smalltalkpro.com Thu Apr 25 03:34:51 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 20:34:51 -0600 Subject: [Seaside] Body tag attributes References: Message-ID: <3CC76B4B.1060306@smalltalkpro.com> Avi Bryant wrote: >On Tue, 23 Apr 2002, Nevin Pratt wrote: > >>Hmmm, seems that if you have a tag with other attributes in the >>template, the other attributes are ignored. >> >>For example: >> ><...munch...> > > >For now, the workaround is this - use a simple in your template, >and do something like > >addBindingsTo: template > (template elementNamed: 'body') > set: #background to: 'http://test.com/mybackgroundimage.jpg' > No, this won't work. And, neither will it work with '~body' instead of 'body' (per my previous post). The problem is in method IAPastWork>>printHtmlTo: You will notice that method hard codes a "" tag, thus with no additional attributes possible. A *very* ugly work-around is to override #printHtmlTo: in my subclass (IATest), and put in the background attribute desired in the override. We need a better fix, though. Nevin From avi@beta4.com Thu Apr 25 03:44:14 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 19:44:14 -0700 (PDT) Subject: [Seaside] Body tag attributes In-Reply-To: <3CC76B4B.1060306@smalltalkpro.com> Message-ID: On Wed, 24 Apr 2002, Nevin Pratt wrote: > No, this won't work. And, neither will it work with '~body' instead of > 'body' (per my previous post). > > The problem is in method IAPastWork>>printHtmlTo: Ack, sorry. Can you tell I'm answering these questions without easy access to the source code? I'll try to get a real fix in SSVS tomorrow. Many, many apologies for the misinformation. I hope you're at least learning something of Seaside in the process ;-). Avi From nevin@smalltalkpro.com Thu Apr 25 04:08:38 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Wed, 24 Apr 2002 21:08:38 -0600 Subject: [Seaside] Body tag attributes References: Message-ID: <3CC77336.1060904@smalltalkpro.com> Avi Bryant wrote: > >Ack, sorry. Can you tell I'm answering these questions without easy >access to the source code? > >I'll try to get a real fix in SSVS tomorrow. Many, many apologies for the >misinformation. I hope you're at least learning something of Seaside in >the process ;-). > >Avi > Of course, also keep in mind that all of the attributes are deprecated in HTML 4.0 (in favor of style sheets). So, I don't know how important a fix for this thing is. I'm still just trying to run my son's Dreamweaver files through Seaside-- that's why I keep hitting these things. Nevin From avi@beta4.com Thu Apr 25 04:14:36 2002 From: avi@beta4.com (Avi Bryant) Date: Wed, 24 Apr 2002 20:14:36 -0700 (PDT) Subject: [Seaside] Body tag attributes In-Reply-To: <3CC77336.1060904@smalltalkpro.com> Message-ID: On Wed, 24 Apr 2002, Nevin Pratt wrote: > Of course, also keep in mind that all of the attributes are > deprecated in HTML 4.0 (in favor of style sheets). So, I don't know how > important a fix for this thing is. Ah, yes. That was it. I *knew* I had some justification for leaving it in such a state. From nevin@smalltalk.org Thu Apr 25 15:42:19 2002 From: nevin@smalltalk.org (Nevin Pratt) Date: Thu, 25 Apr 2002 08:42:19 -0600 Subject: [Seaside] Support for CSS? Message-ID: <3CC815CB.5080706@smalltalk.org> So, does Seaside support CSS? (either as an external file reference or inline) Nevin From avi@beta4.com Thu Apr 25 18:50:05 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 25 Apr 2002 10:50:05 -0700 (PDT) Subject: [Seaside] Support for CSS? In-Reply-To: <3CC815CB.5080706@smalltalk.org> Message-ID: On Thu, 25 Apr 2002, Nevin Pratt wrote: > So, does Seaside support CSS? (either as an external file reference or > inline) Both work, in SSVS. works just like , so you can put external .css files wherever you're putting your .jpgs, and inline style blocks work mostly because of the same hack that messes up , which is that all of the head blocks from nested subcomponents are collected into the top-level . This means that little widgets/subcomponents can add their own Note, however, that the following works just fine when placed in an html file (on my internal network where www.test.com is locally defined as my own machine). Again, it seems to be treated as literal text by Seaside, and thus it is returned to the browser as content, and the browser makes sense of it just fine and fetches the background image: Also, I might add, I have workarounds for *every* issue I've brought up, including this one. I just don't want to propogate them. Nevin From nevin@smalltalkpro.com Thu Apr 25 22:29:23 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 15:29:23 -0600 Subject: [Seaside] Re: Template caching References: Message-ID: <3CC87533.6050804@smalltalkpro.com> Avi Bryant wrote: >On Thu, 25 Apr 2002, Nevin Pratt wrote: > >>OK, I have a few more questions and comments: >> >>1. Anybody know why 'IAPage class >> flushTemplateCache' also walks the >>subclasses and flushes their template caches? >> > >Because the only reason I ever need to flush it is when making changes to >the internals of Seaside, which affects all templates at once. You >shouldn't ever have to manually flush the templates in normal operation. > >Does that answer your other questions too? Or am I missing something? >Of course, there's nothing wrong with adding a method that just flushes an >individual cache, I just wouldn't expect it to be used much. > Hmm, unless I've misunderstood something somewhere, then anytime you make a change to the template (typically found in the #html method), you've got to flush the template cache or the change isn't propogated, and thus you can't test your template change. Otherwise the template cache just keeps holding on to your old IATemplate instance, which of course was built with your old #html. Of course, I could be wrong, and could certainly test my hypothesis easily enough, but that is how it appears to me. Nevin From avi@beta4.com Thu Apr 25 22:39:46 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 25 Apr 2002 14:39:46 -0700 (PDT) Subject: [Seaside] Re: Template caching In-Reply-To: <3CC87533.6050804@smalltalkpro.com> Message-ID: On Thu, 25 Apr 2002, Nevin Pratt wrote: > Hmm, unless I've misunderstood something somewhere, then anytime you > make a change to the template (typically found in the #html method), > you've got to flush the template cache or the change isn't propogated, > and thus you can't test your template change. Otherwise the template > cache just keeps holding on to your old IATemplate instance, which of > course was built with your old #html. No, that would be a huge pain to work with. Any time the #html method is changed (or any other, for that matter), the template cache for that class is automatically flushed. If you're using files, you should be using an IAFileTemplate, which checks the modification dates to do the same thing. You should *not* be manually flushing the template cache. Did you go through the tutorial? Notice that the template is changed many times but you never have to flush the cache. From nevin@smalltalkpro.com Thu Apr 25 22:57:40 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 15:57:40 -0600 Subject: [Seaside] Re: Template caching References: Message-ID: <3CC87BD4.2070506@smalltalkpro.com> Avi Bryant wrote: > >No, that would be a huge pain to work with. Any time the #html method is >changed (or any other, for that matter), the template cache for that class >is automatically flushed. If you're using files, you should be using an >IAFileTemplate, which checks the modification dates to do the same thing. > When you 'accept' a method change (or add a new method), the class method #addSelector:withMethod: is called, which has been overridden in IAPage to flush the cache. Fine. But, if you *programmatically* change the #html, that doesn't happen, because it doesn't involve an actual method change, and thus #addSelector:withMethod: never gets called. Now, the reason I don't used IAFileTemplate is because I don't want the template built directly from the file, which is what IAFileTemplate wants me to do. I instead want to read the html from the file, then programmatically edit it (to handle a few html idiosyncracies automatically), then build the template. Some of the automatic editing are things that, as I said previously, I'm not keen on propogating right now (I want to first learn the framework), so I haven't talked about them (yet). I'm just experimenting right now. But in any case, the point is, if your template html is programmatically generated, the caches don't seem to get flushed. And I can see plenty of uses for programmatically generating the html. Plus, I still think that removing an application should also flush the cache, and it does not appear to do so right now. So, I still stand by my earlier suggestions. But, like I say, I'm not *staunchly* standing by them. I need to learn the frameworks better first. Thanks, Nevin From avi@beta4.com Thu Apr 25 23:10:55 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 25 Apr 2002 15:10:55 -0700 (PDT) Subject: [Seaside] Support for CSS? In-Reply-To: <3CC8743D.4080600@smalltalkpro.com> Message-ID: On Thu, 25 Apr 2002, Nevin Pratt wrote: > I've tried the following embedded CSS code within the header area of an > html file (both with and without the quotes around the background image > URL), and it doesn't seem to be expanded by Seaside (I've set the > document root of the Seaside app to 'http://www.test.com'). Instead, it > seems to be treated as literal text, and thus the browser receives it > just like this, and of course can't make sense of the '@' in the URL. > > Ok, basic misunderstanding here. There is nothing special about the @ character *except* when it's in the attribute of a tag. There is a direct macro expansion from to . In any other context, the @ symbol is, indeed, treated as literal text. When you're used to textual templating systems, this may be a little strange to get used to. It's kinda like the difference between the C preprocessor's macros and syntactic macros in lisp or dylan. By and large, what's going on here has nothing to do with textual expansion. The fact that it sometimes looks like it does is simply a matter of shortcuts and defaults. In other words, all that

is doing, is creating an IAImage element, with an id of 'foo.jpg'. Now, IAImage *happens*, by default, to append the document root to its id and use that as a src attribute. But that's a property of IAImage, not of the @ syntax. Dealing with external resources is clearly a pain, and we'll have to find better ways to do it. From avi@beta4.com Thu Apr 25 23:17:44 2002 From: avi@beta4.com (Avi Bryant) Date: Thu, 25 Apr 2002 15:17:44 -0700 (PDT) Subject: [Seaside] Re: Template caching In-Reply-To: <3CC87BD4.2070506@smalltalkpro.com> Message-ID: On Thu, 25 Apr 2002, Nevin Pratt wrote: > Now, the reason I don't used IAFileTemplate is because I don't want the > template built directly from the file, which is what IAFileTemplate > wants me to do. I instead want to read the html from the file, then > programmatically edit it (to handle a few html idiosyncracies > automatically), then build the template. I might suggest a subclass of IAFileTemplate that does these automatic modifications, so that you still get the automatic update when the file changes on disk. Better yet, write a subclass with a "debugging mode" you can globally turn on or off that always reloads and remodifies the file. Are these programmatic edits that couldn't be handled by the macro system? I'm not saying that changes very much - you still do have to manually flush the caches when you modify your macro code, unless you've got a debugging mode as above. But since that's what the macro system's there for, I'm curious what you're doing that can't be easily expressed in it. From nevin@smalltalkpro.com Thu Apr 25 23:17:44 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 16:17:44 -0600 Subject: [Seaside] Support for CSS? References: Message-ID: <3CC88088.5060806@smalltalkpro.com> Avi Bryant wrote: > >Dealing with external resources is clearly a pain, and we'll have to find >better ways to do it. > Which is precisely why I'm playing around with programmatically "altering" the html, which in turn accounts for my message(s) about the cache not getting flushed. Nevin From nevin@smalltalkpro.com Thu Apr 25 23:34:59 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 16:34:59 -0600 Subject: [Seaside] Re: Template caching References: Message-ID: <3CC88493.1040400@smalltalkpro.com> Avi Bryant wrote: >On Thu, 25 Apr 2002, Nevin Pratt wrote: > >I might suggest a subclass of IAFileTemplate that does these automatic >modifications, so that you still get the automatic update when the file >changes on disk. > I going to do that, but didn't think it had much value when I realized it was my code that was modifying the template, and not necessarily the template file that was changing. Furthermore, I wasn't aware of the cache at the time. I also wondered why IAFileTemplate even bothered to check if the file had changed, because I didn't think template building was a high-overhead activity, and didn't think it was that big of a deal to just update every time. But I think you can see some of these comments reveal inexperience with the framework (even *I* can see that now :-). Subclassing IAFileTemplate might, in fact, be the best way. I'd probably only have to override #parseTemplate, and hook my programmatic editing in there. > >Are these programmatic edits that couldn't be handled by the macro system? >I'm not saying that changes very much - you still do have to manually >flush the caches when you modify your macro code, unless you've got a >debugging mode as above. But since that's what the macro system's there >for, I'm curious what you're doing that can't be easily expressed in it. > I haven't wrapped my brain around the macro system yet, so I can't answer that. Again, though, you might be right. I just don't know. Nevin From tim@sumeru.stanford.edu Fri Apr 26 02:50:42 2002 From: tim@sumeru.stanford.edu (Tim Rowledge) Date: Thu, 25 Apr 2002 18:50:42 -0700 Subject: [Seaside] [BUG][FIX]PWS seaside cannot handle plain url Message-ID: This message is in MIME format which your mailer apparently does not support. You either require a newer version of your software which supports MIME, or a separate MIME decoding utility. Alternatively, ask the sender of this message to resend it in a different format. --615007460--2024647682--134400860 Content-Type: text/plain; charset=us-ascii Yay, my first fix for seaside! If you use seaside with PWS a url of the form 'http://localhost' gets a page with nothing more helpful than 'key not found'. This is because the PWS ActionTable is not fully setup. A simple fix for this is to add the IAPWS to PWS at 'default' as well as at 'seaside'. Another probably useful change is to check the url and to add 'seaside' if it is empty. This then also lets the previous code add 'config' and you get to a useful place. I really dislike websites that go nowhere with a plain url. tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim "bOtHeR," said Pooh, mistaking the LSD tablet for aspirin --615007460--2024647682--134400860 Content-Type: application/octet-stream; name="seaside-defaultURLfix.1.cs" Content-Disposition: attachment; filename="seaside-defaultURLfix.1.cs" Content-Transfer-Encoding: base64 J0Zyb20gU3F1ZWFrMy4yZ2FtbWEgb2YgMTUgSmFudWFyeSAyMDAyIFtsYXRlc3QgdXBk YXRlOiAjNDgxMV0gb24gMjUgQXByaWwgMjAwMiBhdCA2OjQ1OjUyIHBtJyENDSJDaGFu Z2UgU2V0OgkJc2Vhc2lkZS1kZWZhdWx0VVJMZml4DURhdGU6CQkJMjUgQXByaWwgMjAw Mg1BdXRob3I6CQkJdGltQHN1bWVydS5zdGFuZm9yZC5lZHUNDVNpbXBsZSBjaGFuZ2Ug dG8gYWxsb3cgYSBwbGFpbiBVUkwgbGlrZSBodHRwOi8vbG9jYWxob3N0IHRvIGJlIHJl ZGlyZWN0ZWQgdG8gYSB1c2VmdWwgcGFnZSByYXRoZXIgdGhhbiBqdXN0IGRpc3BsYXlp bmcgJ2tleSBub3QgZm91bmQnLg1UaGlzIGlzIGZvciBQV1MgY29ubmVjdGVkIHNlYXNp ZGVzIC0gbm8gaWRlYSB5ZXQgd2hhdCBoYXBwZW5zIHdpdGggQ29tYW5jaGUgc3R1ZmYu DSIhDQ0NIUlBUFdTIG1ldGhvZHNGb3I6ICdhcyB5ZXQgdW5jbGFzc2lmaWVkJyBzdGFt cDogJ3RwciA0LzI1LzIwMDIgMTg6NDInIQ1wcm9jZXNzOiBhUmVxdWVzdCANCXwgdXJs IGFwcCByZXNwb25zZSByZXF1ZXN0IHwNCXVybCBfIChhUmVxdWVzdCB1cmwgZmluZFRv a2VuczogJy8nKS4NCXVybCBpc0VtcHR5IGlmVHJ1ZTpbdXJsIGFkZDogJ3NlYXNpZGUn XS4NCXVybCBzaXplIDwgMiBpZlRydWU6IFt1cmwgYWRkOiAnY29uZmlnJ10uDQlhcHAg XyBJQUFwcGxpY2F0aW9uIGF0OiB1cmwgc2Vjb25kLg0NCXJlc3BvbnNlIF8gSUFQV1NS ZXNwb25zZSBuZXcgcHdzOiBhUmVxdWVzdC4NCXJlc3BvbnNlIGFkZFVybFNlZ21lbnQ6 IHVybCByZW1vdmVGaXJzdDsNCQkJICBhZGRVcmxTZWdtZW50OiB1cmwgcmVtb3ZlRmly c3QuDQkJCQ0JcmVxdWVzdCBfIElBUmVxdWVzdCBuZXcNCQkJCQlmaWVsZHM6IChhUmVx dWVzdCBmaWVsZHMgaWZOaWw6IFtEaWN0aW9uYXJ5IG5ld10pOw0JCQkJCWhlYWRlcnM6 IERpY3Rpb25hcnkgbmV3Ow0JCQkJCXVzZXI6IGFSZXF1ZXN0IHVzZXJJRC4NCQkJCQkN CWFwcCBoYW5kbGVSZXF1ZXN0OiByZXF1ZXN0DQkJIHJlc3BvbnNlOiByZXNwb25zZQ0J CSB1cmw6IHVybC4hICENDQ0hSUFQV1MgY2xhc3MgbWV0aG9kc0ZvcjogJy0tIGFsbCAt LScgc3RhbXA6ICd0cHIgNC8yNS8yMDAyIDE4OjM5JyENc3RhcnRPbjogcG9ydA0JfHRo ZUlBUFdTfA0JUFdTIGxpbms6ICdzZWFzaWRlJyB0bzogKHRoZUlBUFdTIF8gc2VsZiBu ZXcpLg0JUFdTIGxpbms6ICdkZWZhdWx0JyB0bzogdGhlSUFQV1MuDQlQV1Mgc2VydmVP blBvcnQ6IHBvcnQgbG9nZ2luZ1RvOiAncHdzLWxvZy50eHQnLiEgIQ0NDSFQV1MgbWV0 aG9kc0ZvcjogJ1Byb2Nlc3NpbmcnIHN0YW1wOiAndHByIDQvMjUvMjAwMiAxODozNCch DWdldFJlcGx5DQkiR2VuZXJhdGUgYSByZXBseSBiYXNlZCBvbiB0aGUgYWN0aW9uIHNl bGVjdGVkIGJ5IHRoZSBmaXJzdCB3b3JkIG9mIHRoZSBVUkwuIg0NCXwga2V5IHwNCW1l c3NhZ2Ugc2l6ZSA+IDANCQlpZlRydWU6IFtrZXkgXyAobWVzc2FnZSBhdDogMSkgYXNM b3dlcmNhc2VdDQkJaWZGYWxzZTogW2tleSBfICdkZWZhdWx0J10uDQkoQWN0aW9uVGFi bGUgaW5jbHVkZXNLZXk6IGtleSkgaWZGYWxzZTogW2tleSBfICdkZWZhdWx0J10uDQ0J VHJhbnNjcmlwdCBzaG93OiAoJ1JlcXVlc3Q6ICcgLCB1cmwgcHJpbnRTdHJpbmcsICcg ZnJvbTogJywgcGVlck5hbWUsICcgYWN0aW9uOiAnLCBrZXkpIDsgY3IuDQkoQWN0aW9u VGFibGUgYXQ6IGtleSkgcHJvY2Vzczogc2VsZi4NISAhDQ0= --615007460--2024647682--134400860-- From julian@beta4.com Fri Apr 26 03:40:08 2002 From: julian@beta4.com (Julian Fitzell) Date: Thu, 25 Apr 2002 19:40:08 -0700 Subject: [Seaside] [BUG][FIX]PWS seaside cannot handle plain url References: Message-ID: <3CC8BE08.4030609@beta4.com> Tim Rowledge wrote: > Yay, my first fix for seaside! > > If you use seaside with PWS a url of the form 'http://localhost' gets a > page with nothing more helpful than 'key not found'. This is because the > PWS ActionTable is not fully setup. A simple fix for this is to add the > IAPWS to PWS at 'default' as well as at 'seaside'. Hmm... but what if the user is already running something else with PWS... isn't it kind of rude of seaside to overwrite that automatically? > Another probably useful change is to check the url and to add 'seaside' > if it is empty. This then also lets the previous code add 'config' and > you get to a useful place. > > I really dislike websites that go nowhere with a plain url. I agree... but I can't quite see how we can enforce this from the seaside end. It's fair to say that we're taking /seaside but I'm not sure I'm comfortable just blindly throwing ourselves in as the default handler. (IAKom also goes nowhere if you don't give it a path). There are so many ways a web server could be set up and laid out... can we make an assumption that will work? Perhaps we could check if there is already something linked to "default" and if not, then add ourselves? Julian -- julian@beta4.com Beta4 Productions (http://www.beta4.com) From nevin@smalltalkpro.com Fri Apr 26 04:09:31 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 21:09:31 -0600 Subject: [Seaside] [BUG][FIX]PWS seaside cannot handle plain url References: <3CC8BE08.4030609@beta4.com> Message-ID: <3CC8C4EB.5080306@smalltalkpro.com> Julian Fitzell wrote: >> Another probably useful change is to check the url and to add 'seaside' >> if it is empty. This then also lets the previous code add 'config' and >> you get to a useful place. >> >> I really dislike websites that go nowhere with a plain url. > > > I agree... but I can't quite see how we can enforce this from the > seaside end. It's fair to say that we're taking /seaside but I'm not > sure I'm comfortable just blindly throwing ourselves in as the default > handler. (IAKom also goes nowhere if you don't give it a path). > > There are so many ways a web server could be set up and laid out... > can we make an assumption that will work? Perhaps we could check if > there is already something linked to "default" and if not, then add > ourselves? > > Julian > > > I'm using Comanche rather than PWS, but my solution is that if 'seaside' is not already in the URL, then Seaside never gets invoked, and Comanche just handles it. This allows Comanche to handle normal URL's as if Seaside wasn't present. This also means that Comanche handles the empty URL case, and Seaside never sees it. Then, if the URL is truly empty, I look for an 'index.html' file, followed by an 'index.htm' search, in that order. If either file is found, it is appended to the URL, and that is used for the empty URL case. That's more in line with what Apache does. Furthermore, I removed the 'config' append code, making it so that all invocations of the Seaside 'config' app have to be deliberate. I would rather people didn't "accidentally" stumble on the config page, even though it's password protected. All of these changes are in my own "IAKom" class, which I have called "IAComancheInterface". I would have subclassed IAKom to do this, but at the time IAKom only had one method (the #process: method), and it seemed silly to subclass and then override the only method. So, I didn't subclass. Nevin From nevin@smalltalkpro.com Fri Apr 26 04:35:31 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 21:35:31 -0600 Subject: [Seaside] [BUG][FIX]PWS seaside cannot handle plain url References: <3CC8BE08.4030609@beta4.com> <3CC8C4EB.5080306@smalltalkpro.com> Message-ID: <3CC8CB03.7060702@smalltalkpro.com> Nevin Pratt wrote: > I'm using Comanche rather than PWS, but my solution is that if > 'seaside' is not already in the URL, then Seaside never gets invoked, > and Comanche just handles it. This allows Comanche to handle normal > URL's as if Seaside wasn't present. This also means that Comanche > handles the empty URL case, and Seaside never sees it. > > Then, if the URL is truly empty, I look for an 'index.html' file, > followed by an 'index.htm' search, in that order. If either file is > found, it is appended to the URL, and that is used for the empty URL > case. That's more in line with what Apache does. > > Furthermore, I removed the 'config' append code, making it so that all > invocations of the Seaside 'config' app have to be deliberate. I > would rather people didn't "accidentally" stumble on the config page, > even though it's password protected. > > All of these changes are in my own "IAKom" class, which I have called > "IAComancheInterface". I would have subclassed IAKom to do this, but > at the time IAKom only had one method (the #process: method), and it > seemed silly to subclass and then override the only method. So, I > didn't subclass. > > Nevin Oh yea, and I also changed IAComancheInterface (from IAKom) on the class side. It's default starting port is port 80 rather than IAKom's port 8000 default. Plus, I added #stop and #stopOn: class methods so I can easily stop it. Nevin From nevin@smalltalkpro.com Fri Apr 26 06:26:39 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 23:26:39 -0600 Subject: [Seaside] problem restarting servers when VM comes up References: Message-ID: <3CC8E50F.9000908@smalltalkpro.com> I also observed the problem you mention for 3.2g. I found that I could usually manually unregister it from Comanche, then re-register it, and go. But not always. In any case, when I encountered it, I shrugged it off simply because I have a long history of seeing similar problems with images that are saved while connected to databases of various sorts. And it's not just Squeak. I've seen it with GemStone and VisualWorks, too-- where I save an image while logged into GemStone, and then when I relaunch the image, I discover the image is hosed. With GemStone, it depended on which GemBuilder release I used. For most of them, it seemed like GemStone's "official" fix was to autologout (via #snapshot:andQuit:, or whatever VW's equivalent is-- I've forgotten). Thus, the GemBuilder code would force a logout before saving the image. I used to work on the KnowledgeScape project (http://www.kscape.com), and from time to time we hooked in a bunch of things to autohappen just before the image was saved, for similar reasons. Not sure if the current version of the product does any of that, though. In other words, I was not at all surprised to see this behavior with Comanche, and just shrugged it off, vowing to someday put in the "autoshutdown on image save" hook to solve it. But for now I just make sure the server is not running when I save the image. And if I forget, then I rebuild the image :-) "Autohappen" shutdown code is often tricky. Not because it is hard, but because it must be exactly right or you hang things. So I don't particularly like doing "autohappen" shutdown things. But, sometimes it seems necessary. Nevin Jake Donham wrote: >Hi, > >Using Seaside 0.92 with Squeak 3.0 and Comanche 4.10 on a Redhat Linux >6.2 system, if you save and quit while a server is up, the VM crashes: > >Segmentation fault > >1085305112 SystemDictionary>snapshot:andQuit:embedded: >1085305020 SystemDictionary>snapshot:andQuit: >1085304744 TheWorldMenu>saveAndQuit >1085304836 [] in TheWorldMenu>doMenuItem:with: >1085304652 BlockContext>on:do: >1085304008 TheWorldMenu>doMenuItem:with: >1085303640 [] in MenuItemMorph>invokeWithEvent: >1085303916 BlockContext>on:do: >1085304376 [] in BlockContext>valueUninterruptably >1085303824 BlockContext>on:do: >1085304192 [] in BlockContext>valueUninterruptably >1085303732 BlockContext>on:do: >1085303548 BlockContext>valueUninterruptably >1085303456 BlockContext>ensure: >1085303364 Cursor>showWhile: >1085303140 MenuItemMorph>invokeWithEvent: > >I tried Squeak 3.2 gamma, and while it doesn't crash on exit, when I >restart it, the server is not running. However, as far as I can tell >from poking around in ComancheServer, it is still registered in >Comanche's list of active servers, so if you try to start it or set it >to auto-start, Comanche complains that there's already a server on >that port. > >This seems like a Comanche problem rather than a Seaside problem but I >though I might find a friendly ear on this list. If there's somewhere >else I should ask please let me know. > >Thanks, > >Jake >_______________________________________________ >Seaside mailing list >Seaside@lists.squeakfoundation.org >http://lists.squeakfoundation.org/listinfo/seaside > > From nevin@smalltalkpro.com Fri Apr 26 06:40:25 2002 From: nevin@smalltalkpro.com (Nevin Pratt) Date: Thu, 25 Apr 2002 23:40:25 -0600 Subject: [Seaside] tutorial1: form submit method Message-ID: <3CC8E849.1080508@smalltalkpro.com> OK, looking at the following code from the seaside tutorial1: = 42.0 EUR The above is the string for the #html method for the SeasideTutorial class from the tutorial. When that class/app is viewed in the browser, it of course has a button that, when pressed, invokes the #convert instance method in the SeasideTutorial class. Just as the tutorial says it should. OK, good enough. But, what exactly happens if there was *no* action attribute specified in the form tag above, and it is therefore just

rather than ? What method gets invoked then? When I try to test this particular variation (i.e., no action attribute at all), then press the input button in the browser, nothing happens *at all* (that I can tell). I've tried some judiciously placed 'self halt' statements in the Seaside code hoping to intercept it trying to do something, but so far I've come up empty. So, what exactly happens when there is no action attribute specified for the form tag? The reason I am asking is because some server-to-server communication conventions will try to do just that. For example, if you use the IPN (Instant Payment Notification) server-to-server feature of PayPal, then the PayPal server will try to invoke a URL that you have specified, with a form filled with a bunch of hidden input fields. In other words, PayPal will try to POST something very similar to the above html, but without an action attribute specified. I need to know how to intercept such a situation from within Seaside so that I can look at the hidden fields PayPal is trying to send me. Nevin From kamk@volny.cz Fri Apr 26 05:58:32 2002 From: kamk@volny.cz (Kamil Kukura) Date: Fri, 26 Apr 2002 06:58:32 +0200 Subject: [Seaside] Support for CSS? References: Message-ID: <3CC8DE78.8080508@volny.cz> Avi Bryant wrote: >On Thu, 25 Apr 2002, Nevin Pratt wrote: > > > >>I've tried the following embedded CSS code within the header area of an >>html file (both with and without the quotes around the background image >>URL), and it doesn't seem to be expanded by Seaside (I've set the >>document root of the Seaside app to 'http://www.test.com'). Instead, it >>seems to be treated as literal text, and thus the browser receives it >>just like this, and of course can't make sense of the '@' in the URL. >> >> >> >> > >Ok, basic misunderstanding here. >There is nothing special about the @ character *except* when it's in the >attribute of a tag. There is a direct macro expansion from > to . >In any other context, the @ symbol is, indeed, treated as literal text. > > Exactly. Instantly, I tried the following and it worked :) -- Kamil From kamk@volny.cz Fri Apr 26 06:49:17 2002 From: kamk@volny.cz (Kamil Kukura) Date: Fri, 26 Apr 2002 07:49:17 +0200 Subject: [Seaside] Support for CSS? References: Message-ID: <3CC8EA5D.8070801@volny.cz> --------------090205080300000604000405 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit > > >On Thu, 25 Apr 2002, Nevin Pratt wrote: > >>So, does Seaside support CSS? (either as an external file reference or >>inline) >> >> >Both work, in SSVS. works just like , so you can put >external .css files wherever you're putting your .jpgs, and inline style >blocks work mostly because of the same hack that messes up , which >is that all of the head blocks from nested subcomponents are collected >into the top-level . This means that little widgets/subcomponents >can add their own