seaside August 2011

seaside@lists.squeakfoundation.org

47 participants
45 discussions

debugging javascript within browsers is hard when the browser show the response on a single line
by Nick Ager 05 Jul '14

05 Jul '14

Hi, I wonder if other people suffer from the same problem when debugging javascript: Seaside's response is viewed by browsers as a string without line-breaks. Normally this isn't a problem as the browser "pretty-prints" the output when inspecting the html. However when debugging javascript, either inline or within a file-library the script debugger (I'm currently using Mac Safari) shows the output as a single line - which makes it impossible to interpret any javascript generated errors ("syntax error: line 1"!!) or to set meaningful breakpoints. I've discovered that calling #withInternetLineEndings on the file-library string results in browsers interpreting the line-endings as expected. Locally when I'm debugging I've created a class derived from WAHtmlDocument, which overrides #nextPutAll: WAHtmlDocumentWithInternetLineEndings>>#nextPutAll: aString super nextPutAll: aString withInternetLineEndings and I modify WAFileLibrary>>#handle: modifying the WAResponse>>#document: to: document: ((self documentForFile: fileName) withInternetLineEndings) Is there a better solution? Are there easier workarounds, browser settings etc. I created an issue for this problem: http://code.google.com/p/seaside/issues/detail?id=675 Though if there are easy workaround that I've missed, I'd be delighted to close the issue. Thanks Nick

6 13

Handling expired Session in Seaside 3.0
by Udo Schneider 13 Apr '12

13 Apr '12

All, if this is just an RTFM question I'm happy to read on my own ... however I'm searching for a solution to handle expired sessions in Seaside 3.0. My goal is to either display a specific component when a request for an expired session is recieved or to be able to find out if a request was for an expired session in my initial component. Any pointers? CU, Udo

4 8

ESUG SummerTalk - Fuel, binary object serializer
by Martin Dias 28 Feb '12

28 Feb '12

Hi folks. I am really happy to announce that ESUG is sponsoring me for Fuel development through the ESUG SummerTalk. I am Martin Dias, a student at Buenos Aires, Argentina. The idea behind this SummerTalk is to implement Fuel, a binary, fast and general-purpose object graph serializer in Pharo<http://www.pharo-project.org/>. It is based on VisualWorks' Parcels ideas. Actually, the project has already started since several months. Tristan Bourgois and I started with the project while doing an internship with RMoD, INRIA <http://rmod.lille.inria.fr/web/pier>. Since a couple of months, Mariano Martinez Peck <http://marianopeck.wordpress.com/> joined the team, and now he is the official mentor in the SummerTalk. ESUG website for SummertTalk: http://www.esug.org/wiki/pier/Promotion/SummerTalk/SummerTalk2011 The website with all the necessary information is here: http://rmod.lille.inria.fr/web/pier/software/Fuel It even includes slides explaining the algorithm. In addition, a paper is in progress. For the moment, Fuel already provides the following features: - Fast pickle format. It is much faster to materialize than to serialize. - Correctly support class reshape (when the class of serialized objects has changed). - Serialize ANY kind of object. For the moment there is no object to our knowledge that we cannot serialize and materialize. - Be able to completely serialize classes and traits (not just a global name). - Support cycles and avoid duplicates in the graph. - Integration to Moose <http://www.moosetechnology.org/> with an extension to export and import their models. - Detection of globals: for example if you serialize Transcript, it is not duplicated and instead managed as a global reference. - Solve common problems like Set rehash. - Buffered writing: we use a buffered write stream for the serialization part (thanks Sven!). - No need of special support from the VM. - Try to have a good object oriented design. - Well tested (about 120 tests, for the moment). - Large set of benchmarks (even benchmarks for Moose extension). And of course, there are a lot features for the future. You can see some of them in the website and some in the issue tracker: http://code.google.com/p/fuel/issues/list We really appreciate all kind of feedback and comments. If you want to try it, check in the website how to do it. It is extremely easy. Once again, I want to thank a lot to ESUG for sponsoring the project. I plan to create a "news" section in the website with some RSS. I will keep you informed. Best regards, Martin

5 12

Seasidehosting not working ?
by Hilaire Fernandes 14 Jan '12

14 Jan '12

I still have probleme to make working seaside hosting. I took a fresh image from the last pier one-click distribution (no save operation from the image), upload it to cyclades.seasidehosting.st, but still the image can't be runned. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire

10 13

File Directory error (Pharo 1.2.1)
by Robert Sirois 14 Dec '11

14 Dec '11

Here's the error when adding or using a file directory: The method SmalltalkImage platformName has been deprecated.Use Smalltalk os platformName RS

4 9

Static serving of jQuery and related files - reg.
by muthu kutti 14 Nov '11

14 Nov '11

Hi All! I would like to move jQuery and related files out of the image have them served directly by Nginx. How do I go about doing that? Thanks in advance. Muthu

6 6

send email with seaside
by Simon De Baets 09 Nov '11

09 Nov '11

Hello, I build a website with seaside3 / pharo. I want to send email to the users of my website but i don't know how can i do this. So how can i send an email with seaside? Thanks, Simon

5 4

Re: Anyone building seaside images on a mac with Jenkins?
by Stephan Eggermont 28 Oct '11

28 Oct '11

Thank you Sven. Do you also have a diff for build-oneclick.sh? chmod on 10.6.7 has no --reference. I noticed in the history a 'now also mac works' which has the same line. Stephan

5 5

Re: Anyone building seaside images on a mac with Jenkins?
by Stephan Eggermont 28 Oct '11

28 Oct '11

Lukas wrote: >If anybody knows how to make the build scripts more portable, please >lt me know. I don't have much bash scripting experience. I wrote and >tested the scripts only on Ubuntu Server. In the answers on http://stackoverflow.com/questions/5753687/replacement-for-chmod-reference-… it looks like stat -f can provide the mode more portable. Stephan

2 1

custom error handling results in: "Error: context not in self"
by Nick Ager 01 Sep '11

01 Sep '11

Hi, I'm using a hidden iframe in my file upload component. If an error occurs during uploading, the error page is rendered in the hidden iframe - which means I end up debugging by inspecting the http responses in the browsers development tools. Not ideal so I thought I'd trap the error and present the page myself. In the exception trap I send a script to the page which redirects the parent window to the error page - 'parent.parent.window.location.replace(..error url..)' This works well apart from when I click on the "debug" link, the debugger in the Pharo reports: "Error: context not in self" and doesn't shows an unrelated (to the original error) stack trace. I've patched together my error handling code, by examining the error handling filter in Seaside. I've had to add an accessor on WASession>>#continuations, which probably indicates there is an easier way to achieve my goal: handleException: ex | session requestContext key continuation renderContinuation | requestContext := self requestContext. session := requestContext session. key := requestContext request fields at: session actionField. continuation := session continuations at: key. renderContinuation := continuation createRenderContinuation. session presenter show: (WAWalkback current exception: ex) onAnswer: [:answer | answer ifTrue: [ self flag: #todo. "work out why I get the error: 'Error: context not in self'" GRPlatform current openDebuggerOn: ex ] ]. "redirect the main page to the error location" self requestContext respond: [ :response | response contentType: WAMimeType textHtml; nextPutAll: (WARenderCanvas builder fullDocument: true; scriptGeneratorClass: JQScriptGenerator; "removes the onload from body" render: [ :html | html script: 'parent.parent.window.location.replace("', renderContinuation registerForUrl greaseString, '")' ] )] I've a horrible feeling I'm missing an obvious, simpler solution Thanks, Nick

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside August 2011