gmane.comp.lang.smalltalk.squeak.seaside

RE: [Newbie] Storing state in cookie instead of URL

Sebastian Sastre — 2008-09-07T21:03:45

...am I correct then in thinking that the _s tells Seaside which session is the request about and _k which continuation performs the next step. The continuation has a snapshot of the state of all the objects that process needs to continue from there. So it wont find, it is :) not become water, be water my friend, be water... ;) Cheers and welcome to the beach! Sebastian

Re: [Newbie] Storing state in cookie instead of URL

Philippe Marschall — 2008-09-07T20:36:52

2008/9/7 Stef Telford ummon.com>: No, it is stored when you view the first "page". No, the value of _k changes over the session lifetime. The value of _s does not. Cheers Philippe

RE: #script: part of the tags

Sebastian Sastre — 2008-09-07T19:44:27

No is not written (that's why the controversy happens) and as you may have read, I've suggested to decide in favor of mimic an intuitive example instead of technical ones. In fact is not me, the word "brush" (in the class name) is already suggesting that. I understand that could be a convenience at first but in the end balance changes. So novices can be surprised after some time the same as not novices do. Clarifiying, by "magic" I mean seaside doing the abstraction for you behind the scenes. By "too much magic" I mean deciding an implementation which is not obvious and is counterintuitive. I don't see #scriptOnLoad: as revealing implementation. I see it is revealing when (not how) it will execute the script. I'm ok with hiding the implementation but, as it makes all the difference, I'm not ok with hiding the implementation *and* the moment. Ok, IMHO that mitigation is a step forward. You may not need it yet but that event, as previously said, is not only useful. Is critical for enhancing user experienc

Re: Scriptaculous SUInsertion doesn't work in IE7

Vladimir Pogorelenko — 2008-09-07T18:19:03

Changed code to a new API. But found that the problem was caused by another reason. Shortly, now problem is gone. Many thanks Lukas for a quick response. Happy that now application works in IE. Previously with non-ajax version I've wrapped every just created item with special decoration which just wraps the component with (giving ability to refer to small part of page with just created component). Also I did updateUrl: anUrl fragment: 'locus'. to add #locus to the url. By that I reaching the ability to have page opened at just added component. It was helpful when the page more than one screen long. When I add this "locus" decoration to a just created component with ajax I got such wrong behaviour in IE. Don't know really why. But now I think don't even need to use this decoration. Still will include my code: WAAnswersEdit renderAddAnswerActionOn: html html anchor id: html nextId; onClick: (html element id: placeForAnswerID; insertBottom: [:r | self addA

Re: [Newbie] Storing state in cookie instead of URL

Randal L. Schwartz — 2008-09-07T17:51:39

Lukas> The back-button of you web-browser would stop to work, because Lukas> browsers don't backtrack cookies. And even storing _s in a cookie is problematic if you want two different windows open with two different "sessions", which I'll often do when I'm comparing different flights on the same airline.

Re: [Newbie] Storing state in cookie instead of URL

Stef Telford — 2008-09-07T17:50:55

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philippe Marschall wrote: Ahhh.. judging from the reply, am I correct then in thinking that the _s (session key) is then stored in the cookie after login/authn/authz and because Smalltalk/Seaside has to grab objects from the continuation, it has to know the _k value so that it can then find the user objects, page objects, etc ? In other words; To be able to get the objects (including the cookie object), we need the _k outside so Smalltalk/Seaside can find it. If that's the case, then the _k outside makes sense, and something I may have to live with :) Thanks for the quick reply btw.. pretty amazed - thank you :) Stef -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjEFH8ACgkQANG7uQ+9D9U8fgCaApVhjFJiP0E471cppgHYAy8m i0cAn3pFpRAF651M216bgKD0xt0pOqbC =qHLM -----END PGP SIGNATURE-----

Re: [Newbie] Storing state in cookie instead of URL

Lukas Renggli — 2008-09-07T17:40:08

The back-button of you web-browser would stop to work, because browsers don't backtrack cookies. Cheers, Lukas

Re: Scriptaculous SUInsertion doesn't work in IE7

Lukas Renggli — 2008-09-07T17:38:37

SUInsertion is deprecated in the JavaScript library, it is only there because SUAjax requires it at some places. Do you experience the same problem if you use the following code? html unorderedList id: 'list'. html anchor onClick: (html element id: 'list'; insertBottom: [ :h | h listItem: 'item' ]); with: 'add' Or could you send an example so that we can reproduce? Cheers, Lukas On 9/7/08, Vladimir Pogorelenko livesystems.ru> wrote:

Re: [Newbie] Storing state in cookie instead of URL

Philippe Marschall — 2008-09-07T17:35:46

2008/9/7 Stef Telford ummon.com>: Not at all. the _s value (he session key) Cheers Philippe

[Newbie] Storing state in cookie instead of URL

Stef Telford — 2008-09-07T17:30:46

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, So, I am playing around with Seaside.. generally digging it and glad that I can do web development in my favourite language (Ruby is nice, but, well, Smalltalk is nicer ;). I have taken the first rudimentary steps, running Wakom, creating a simple page and storing state. However, when I was in the configure panel for my application, I switched the 'Use Session Cookie' to 'true', yet I still get the _k in my URL. I would have expected the value for _k to be stored in the session cookie. If this doesn't do this, then I have two questions; 1) how do I get Seaside to use _k in cookies ? and 2) what -does- 'use session cookie' do, if it doesn't put the state (_k) into the cookie ? Also, if anyone has some nice fileouts of more examples, that would be great. I tend to learn from taking things apart :) Thanks and Kudos on giving Smalltalk a nice web framework :D Regards Stef -----BEGIN PGP SIGNATURE----- Version:

Scriptaculous SUInsertion doesn't work in IE7

Vladimir Pogorelenko — 2008-09-07T17:27:25

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

Re: #script: part of the tags

Lukas Renggli — 2008-09-07T16:50:46

That's not a written rule about brushes. There are a couple examples that don't have immediate effect on the generated XHTML. I agree that this should be better documented though. I have given dozens of Scriptaculous tutorials to Smalltalk/Seaside/JavaScript novices and this has never been a problem. WATagBrush>>#script: does exactly what one expects in most cases, without forcing you to know all the internal details. If this method was called #scriptOnLoad: you would be talking about the implementation already. Moreover it would cause a confusion between #scriptOnLoad: and #onLoad:. Again, the purpose of #script: is to assign a paricular script to a tag (that's an abstraction over what you can do in plain XHTML/JavaScript) and Seaside figures out the rest for you. I don't even see magic here. I've added a method comment in Scriptaculous-Core-lr.36. I disagree. The purpose of #script: and #addLoadScript: is to add scripts that evaluate when the page, all styles and images have completed loading. The

RE: #script: part of the tags

Sebastian Sastre — 2008-09-07T15:50:01

Hi Lukas, No I'm not mistaken about them, they both do have sense to me too. The difference is about overload of the term. I'm recommending them to be explicitely disambiguated instead of ambiguos. If the tag is designed to allow a script just below it (making aside the elegance or not of using it at all), then when I talk to a brush tag and I say "script" I dont expect the *enhancement* of seting the script somewhere else the same way you say to it "attributeAt:put:" and you dont expect it to be set somewhere else. The object is a brush to invoke the concept of you "talking" to a brush that you would expect it to paint there where it is instead of somewhere else. Take the same experience but with a more tangible one: will be frustrating to have a pen in your hand that when you say to it "pen please write hello" it do that in the reverse of the notebook without even telling you about. Will be cool to have a pen which responds to voice commands but will be uncool that it does it being too much smart.

Setting up GLASS on Slicehost

James Foster — 2008-09-07T15:35:42

On Aug 18, 2008, at 3:05 PM, itsme213 wrote: I've started a series of posts at http:// programminggems.wordpress.com/ that describe the process of installing GLASS on Slicehost. James Foster

Re: #script: part of the tags

Lukas Renggli — 2008-09-07T14:41:38

This is not a silent decision of Seaside, this method had been there since the very beginning of the Scriptaculous package: Name: Scriptaculous-avi.4 Author: avi Time: 22 September 2005, 1:59:03 pm UUID: b4f48653-2bab-11da-9fc6-000a95db7844 Ancestors: Scriptaculous-avi.3 Support #script: so that elements can have effects applied to them immediately. I think you mistake WATagBrush>>#script: for WAHtmlCanvas>>#script:. The two are something entirely different and both make perfect sense to me. Check out "Adding JavaScript" from the slides 13, 14 and 15 of my Seaside tutorial for a detailled explanation: . Cheers, Lukas

#script: part of the tags

Sebastian Sastre — 2008-09-07T13:00:21

Hi there, Today I've found a surprising behavior (about a 'dom:loaded' event reaction which was not executing) and debugging that lead me to the #script: method of WATagBrush which has this code: script: aPrototype aPrototype isNil ifTrue: [ ^ self ]. (aPrototype respondsTo: #id:) ifTrue: [ aPrototype id: self ensureId ]. aPrototype session addLoadScript: aPrototype That means that silently Seaside decided to put the script part of the tag in the onLoad section which is IMHO a very poor choice this days. If the idea is to mantain that silent manipulation of the script tag, I recommend a review to use 'dom:loaded' instead of that because it will be fired just after the html is loaded and before the images are loaded and, depending on the page, that could make a lot of diference to the user experience. If not, I recommend two methods. One called #script: behaving as intuitively expected for the tag and other with the "enhancement" but making it explicit with something like #onDOMLoadedScript: so th

Re: [ANN] seaBreeze in Cincom public store

Philippe Marschall — 2008-09-05T16:23:42

2008/9/5 stephane ducasse free.fr>: Only if shortsighted managers are involved. Exactly how many non-open Smalltalk web frameworks are left? Do you think this a coincidence? Cheers Philippe

Re: [ANN] seaBreeze in Cincom public store

stephane ducasse — 2008-09-05T15:37:06

I applaud this free licensing! Sharing is often more difficult than not :) Stef On Sep 5, 2008, at 3:44 PM, Magnus Schwarz wrote:

[ANN] seaBreeze in Cincom public store

Magnus Schwarz — 2008-09-05T13:44:36

We just published the Visualworks version of seaBreeze to the Cincom public store! Feel free to load it into a VW7.6 image and play around. For all the bugs you find and enhancements you require please look at http://seabreeze.heeg.de At the "Developer" tab you find the address of the related Google issues list and the mailing list we installed. Enjoy, Magnus BTW: Please tell us when you finished the port to Squeak and GemStone :)

Re: Re: [ANN] seaBreeze for Seaside (Nevin Pratt)

Sean Allen — 2008-09-04T05:23:55

and gemstone! On Sep 3, 2008, at 4:06 PM, stephane ducasse wrote:

Re: Re: [ANN] seaBreeze for Seaside (Nevin Pratt)

stephane ducasse — 2008-09-03T20:06:52

I imagine that everybody could port it to squeak since the license is MIT. Stef On Sep 3, 2008, at 10:04 PM, Nevin Pratt wrote: