gmane.comp.lang.smalltalk.squeak.seaside

Re: OSCON "contest"

cdrick — 2008-07-25T08:29:03

Are there Pragma in Gemstone ? If yes I'll suggest looking at SSFormand SSFormTest in Ramon image (http://onsmalltalk.com/downloads/DevImage.zip)... Otherwise, I think one could publish in a repository a small table component that add/edit/remove collection entries (based on conventions on object accessors) having a simple validate function ;)... There's a need anyway for such a component. It could even be a project in itself to expose several variations of tables... without any apriori relation to the oscon app :) My 2 cents Cédrick _______________________________________________ seaside mailing list seaside< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: OSCON "contest"

Chris Dawson — 2008-07-25T05:10:40

_______________________________________________ seaside mailing list seaside< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: OSCON "contest"

James Foster — 2008-07-25T04:10:32

I did try it both ways and building the editor by hand seemed to be more lines of code and I thought I'd go for something that might seem more familiar for the domain definition. Also, since I was building one component by hand trying the other as meta data seemed like reasonable variety. On the other hand, since I don't consider the whole experience a great success I certainly won't insist that I made the right choice. Agreed. Maybe next time I'll channel the better-known "James" and try a demo of Web Velocity! James Foster

RE: OSCON "contest"

Ramon Leon — 2008-07-25T00:54:07

Nope, but I wouldn't be showing them Magritte either, that's a mistake, I'd be showing them Seaside and Scriptaculous. Magritte is complex in the same way Glorp is complex, building all those metadata descriptions is complex and error prone and takes way too much time to use in a demo, especially a time limited one. Whipping up something in raw Seaside would be much faster unless you've rigged up some code generators to write the mappings automatically for you. Rails guys are accustomed to ActiveRecord and scaffolding which bootstraps them up to a running system very quickly using code generation and a generate and modify philosophy (this is also how they learn Rails). Gemstone might eliminate the need for ActiveRecord, but Magritte is not at all equivalent to scaffolding. Scaffolding is much easier to hack and customize because it's not a framework, it's just a bunch of generated form template code. To compete against Rails in a time limited demo, you'll need something like a scaffolder, or a form b

Re: OSCON "contest"

James Foster — 2008-07-24T23:49:06

On Jul 24, 2008, at 3:41 PM, Igor Stasenko wrote: And if you were invited to a Ruby event and asked whether Seaside/ Magritte could support JavaScript, would you tell them that they were wrong for asking? James

Re: OSCON "contest"

Igor Stasenko — 2008-07-24T22:41:42

2008/7/24 James Foster jgfoster.net>: Well, i really don't think that validating forms using javascript is good way. Because it is not secure, and often you need more additional data to validate an input, which accessible only at server side and hidden from client's eyes. Oh, and btw: good user interface should not show any 'yes-no' dialogs :) UI should be built on a principle which allows user do things first, without asking 'yes-no' all the way around, and then allow to revert things back (undo) at any the moment when he finds he made wrong action(s).

Re: OSCON "contest"

James Foster — 2008-07-24T19:16:21

_______________________________________________ seaside mailing list seaside< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: OSCON "contest"

James Foster — 2008-07-24T19:13:11

On Jul 24, 2008, at 8:51 AM, Igor Stasenko wrote: That does look nice, though I believe it does require execution of server code to handle the dialog. What drove me to do the extension was the "requirement" to use JavaScript so that the server code only ran if the user confirmed based on code running only on the client. James

Re: OSCON "contest"

Igor Stasenko — 2008-07-24T15:51:13

2008/7/22 James Foster jgfoster.net>: Here the simple class which draws a dialog using lightbox. Just add a method , like this: confirmDialog: aTitle with: aContentsBlock ^ self lightbox: (TheDialogWindow confirmDialog: aTitle with: aContentsBlock) and then you can use it like this: html submitButton value: 'Delete this worthless stuff'; callback: [ (self confirmDialog: 'Deleting worthless stuff' with: [:htm | htm text: 'Do you really think this stuff is worthless?'] ) ifTrue: [ self deleteStuff ] ]. Note, that you can put any html inside a dialog window. Try it out :)

Re: OSCON "contest"

Conrad Taylor — 2008-07-24T15:34:38

_______________________________________________ seaside mailing list seaside< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: OSCON "contest"

Randal L. Schwartz — 2008-07-24T15:29:08

James> Yes, Web Velocity would have been well suited for that. And Randal has James> a copy :) I was thinking it would be funny if I pulled out my laptop and started from scratch with WV while the GS team was competing. :) The real problem seemed to be that there's a lot of code to type to describe the meta data (Magritte)... but once that code is typed, lots of things are available in very flexible ways. The other frameworks essentially intermix metadata and uses of that data, and would spend a lot longer to *change* the result once built. And we all know, the majority cost of software is not initial development, but *maintenance* in reaction to changing minds^Wgoals of the customer. For example, had the contest been to start with your already built application and then simply *add* the rating, the GS team would have been done in 3 minutes, while the other teams (I suspect) would have taken longer, especially to figure how how to migrate their persistent schemas. Also, James Foster - you gotta learn

Re: OSCON "contest"

James Robertson — 2008-07-24T14:47:53

Yes, Web Velocity would have been well suited for that. And Randal has a copy :) James Robertson Cincom Smalltalk Product Evangelist http://www.cincomsmalltalk.com/blog/blogView Talk Small and Carry a Big Class Library On Jul 24, 2008, at 10:38 AM, James Foster wrote:

Re: OSCON "contest"

James Foster — 2008-07-24T14:38:26

I'd like to thank all of you for your interest and support as we prepared for this competition. Now for the report... Overall I'm disappointed with my performance. 20 minutes is just too short a time for building even a trivial application using GLASS. The analogy that comes to mind is this competition (race) was a sprint and we are much better suited to competing in a marathon. There was a point a couple days ago when I told people that we'd do better if we got a beta copy of Cincom's Web Velocity from James Robertson and used it for the competition. I think they (Cincom) are doing an excellent job at aiming at this sort of audience. James Foster On Jul 16, 2008, at 2:46 PM, Kyle Dawkins wrote:

onComplete: and later

Norbert Hartl — 2008-07-24T07:38:50

In the method comment of SUAjax>>onComplete: there is "possible automatic behaviors" mentioned. What does that mean? I'm trying to execute a piece of javascript code after a updater request has been sent, the returned element has been included in the DOM and returned scripts are executed. Is there any chance to do this or what would be good approach? What I'm trying to achieve is that in an updater callback an element is rendered and a piece of javascript which creates a new object. After the updater return is received and the element is hooked in the DOM and the code created the object I like to trigger a function that registers them both at global object. thanks in advance, Norbert

Re: Back button question

itsme213 — 2008-07-24T03:52:09

"Julian Fitzell" fitzell.ca> wrote in message Reasonably sure, as responsiveness degrades over time (may be other causes to, I'm not sure which objects/inst vars to inspect to actually verify this - any hints?). I don't think its a multi-user issue, more from doing something outside the designed-for boundary of Ajax in 2.8. Thanks, will do that. Sophie

Re: Back button question

Julian Fitzell — 2008-07-24T02:55:45

First, are you sure it's a problem? I wouldn't worry about optimizing this until you have so many users that you're running out of resources. However, the simplest solution (I think) would be to subclass WASession and implement #initialize initialize super initialize. continuations capacity: 10. "or however many continuations you want to keep around" The default capacity is 20. Julian On Thu, Jul 24, 2008 at 6:43 AM, itsme213 hotmail.com> wrote:

Back button question

itsme213 — 2008-07-23T22:43:45

Most interaction in my app is Ajax based. Due to some Seaside 2.8 restrictions I am using Lukas' #in:do: workaround for updating/re-rendering one component from the callback of another. This seems to cause the callback count to increase with time (at least the little callback numbers in Seaside generated links keep increasing) _s=i178duf&_k=usj27a&45 <- 45 OK, so I sometimes do an explicit whole-page refresh html anchor callback: [WARenderLoop new call: self] with: 'Explicit Refresh' This of course enables the back button, presumably keeping around stuff that is meaningless for my application. I'm hoping for a simple way to free up at least some of the resources (e.g. large number of callbacks? some RenderContinuations/Contexts/or similar?) left around to support the back button. Is anything like isolate: applicable? html anchor callback: [self isolate: [WARenderLoop new call: self]] with: 'Explicit Refresh' Other suggestions? Thanks - Sophie

Re: Re: Re: [squeak-dev] [Q] File Upload/Download Server,Comanche or Swazoo

Philippe Marschall — 2008-07-23T21:17:10

2008/7/23 Janko Mivšek eranova.si>: Nope sorry. See the attached code. Your example and the attachment work only if there is an upload filed with the name 'file'. That's the only upload filed that will be streamed. That's why the attached code breaks. If you change the name of the upload field to 'file' then the code breaks somewhere in MultiByteFileStream (Squeak 3.9 Mac VM). Cheers Philippe _______________________________________________ seaside mailing list seaside< at >lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Re: Seaside Security

Hans N Beck — 2008-07-23T20:30:49

Hi, ok, clear, thanks for explanation :-) yeah, in Firefox, if deleting "private data", it works, Safari doesn't work even if triggering "Empty Cache". Anyway, it's clear now. Thanks for help! Hans

Re: Re: Re: [squeak-dev] [Q] File Upload/Download Server,Comanche or Swazoo

Janko Mivšek — 2008-07-23T20:20:40

Not knowing names of the fields is the whole point of "deferring" parsing the POST request until this information is known. Deferring means that request is not read and completely parsed already by Swazoo but lately, when some post data is first needed. That allows you to delay streaming too, until you have enough info where to stream and to open the destination file accordingly. See this example from http://www.swazoo.org/streaming.html: Site>>answerTo: aHTTPRequest | stream | aHTTPRequest postDataAt: 'file' beforeStreamingDo: [:datum | stream := (SpFilename named: datum filename) writeStream. datum writeStream: stream]. aHTTPRequest ensureFullRead. "to be sure streaming occurs" stream close. "mandatory, to close open stream! " ^HTTPResponse ok In that example we open a file named as the original file, which is sent in request as post data, just before a file content. I hope that helps Best regards Janko

Re: Seaside Security

Lukas Renggli — 2008-07-23T19:43:57

Again the story with Apache. The Squeak image servers all applications on port 8080 that is hidden behind the firewall. This means from outside the server I cannot access port 8080. Then there is Apache that proxies requests to www.myapp.com to localhost:8080/seaside/myapp. When I want to access the config application I go to the server (or use a tunnel) to access localhost:8080/seaside/config. Did you set the username and password in the config application? It could also be that your web browser caches the authentication somehow. So you only need to enter it once. Cheers, Lukas