seaside January 2018

seaside@lists.squeakfoundation.org

11 participants
7 discussions

isolate
by recursive68＠gmail.com 26 Nov '19

26 Nov '19

Hi, Given it looks like the isolate method is never going to added back to the current or future versions of Seaside as it's been an open bug issue for the last 5 years, how in general would go about replicating it's behaviour ? I think it's a shame as I think this sort of functionality made Seaside standout from the crowd as a web framework. Thanks

4 5

Seaside 3.2.4 bugfix release available
by Johan Brichau 25 Feb '18

25 Feb '18

Hi all, Seaside 3.2.4 fixes an important bug [1][2]. If you are on 3.2.x, you want to upgrade. cheers Johan [1] https://github.com/SeasideSt/Seaside/issues/932 <https://github.com/SeasideSt/Seaside/issues/932>[2] https://github.com/SeasideSt/Seaside/issues/909 <https://github.com/SeasideSt/Seaside/issues/909>

3 8

OT - broken message
by Markus Fritsche 31 Jan '18

31 Jan '18

Hya, sorry for offtopic - was this last message broken for everyone or just me? Kind regards, Markus Am 31.01.2018 um 08:50 schrieb : > I name all the HTML rendering methods with the `renderSomething...On:`, so

3 2

Validating inputs before calling callback using AJAX serialization
by Esteban A. Maringolo 18 Jan '18

18 Jan '18

Hi all, I'm trying to find a clean and "proper" way of dealing with the validation of user entered values in forms _before_ they hit the callback block. And based on such validation result be able to respond one script or another. Let's say I have something like html textInput onChange: (html jQuery ajax serializeThis); script: (html jQuery script: [:s | "fancy things that modify the web UI" ]; callback: [:value | self doSomethingWithValue: value] The problems with that are: a) I can't "sanitize" the input before it reaches the callback block, I have to do it within the callback block. b) I have no way to return one script for a successful validation, and one for a failing one. I'd like something like A) html textInput onChange: (html jQuery ajax serializeThisValidating: validationBlock successScript: [:s | "fancy things that modify the web UI" ] failureScript: [:s | "modify the web UI reporting the failure" ]); callback: [:value | self doSomethingWithValue: value] or... B) html textInput onChange: (html jQuery ajax serializeThis); callback: [:value | self doSomethingWithValue: value ] validation: aBlock successScript: [:s | "fancy things that modify the web UI" ] failureScript: [:s | "modify the web UI reporting the failure" ]. I think that the A option is the best alternative, since all the "special handling" will happen in the context of the JQAjax and maybe a special kind of JSAjaxCallback). Also I don't know how this would work in the context of _several_ validated callbacks, but I plan to make it work in the context of #serializeThis only. But I'm sure there is a simpler way of achieving this, since I tend to make things complicated. Any suggestions? Esteban A. Maringolo

2 2

random maddening bug - "corrupted" file upload contents
by Cyrille Delaunay 17 Jan '18

17 Jan '18

Hi everyone, Since some times, we are experimenting a random bug while using seaside file upload. Not sure at all about the exact origin of this issue (Application specific, Zinc, Seaside, Pharo ?). But as it start to drive us mad, I'm sharing our problem with you. Maybe someone would already have experimented something similar or would have a good feeling about the issue. *High level description:* We have a file upload element rendered with seaside. The callback of this file upload element is triggered when the form is submitted via a submit button. Problem: Within this callback, the raw contents of the WAFile does not match the expected contents of the selected file. The first 4 bytes are "wrong", and rest of the byte array seems ok. This issue occurs randomly and we haven't been able to determine / guess any context criteria. *Debugging:* In order to figure out what was wrong, we tried to catch a place in pharo where file contents started to differ from the expected file contents. The earlier upload step in which we have been able to notice this delta, is method ZnMultiThreadedServer >> executeOneRequestResponseOn: In this method, a http request is read and materialized from an input stream, >From my naive point of vue, this stream looks like a kind of communication entry point between the web browser and pharo. The zip input file I am trying to upload is expected to begin with the following bytes: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 ... The request object built within #executeOneRequestResponseOn: points to an"entity" variable, which points to a "parts" variable, which points to a single ZnMimePart. This ZnMimePart points to a byte array beginning with: #[0 0 0 0 10 0 0 0 0 0 125 83 67 73 ... I also experimented another case where The request object built within #executeOneRequestResponseOn: points to an"entity" variable, which points to a "parts" variable, which points to multiple ZnMimePart. One of the ZnMimePart points to a byte array beginning with: #[138 67 80 75 10 0 0 0 0 0 125 83 67 73 We can see that in both cases the first 4 bytes do not match the expected first 4 bytes of the file. As a consequence, later in our process, pharo gets a error while trying to unzip this upload file, complaining about a "'bad LH signature at 0'". Does this speak to anyone ? -- Cyrille Delaunay

5 17

WAComponent instances tree + proper page refreshing for user (back button) - confusion
by Petr Fischer 16 Jan '18

16 Jan '18

Hello! I'm slightly confused about - how to properly refresh instantiated WAComponent tree and when. In the Seaside manual says (About Callbacks): "Do not change state while rendering... Just produce output and define callbacks that do the fancy stuff you can’t do while rendering." OK, then my small example: 1) Suppose I have a page - WAMyListPage (WAComponent sub class), which presents a list of items from DB table, easy. 2) When WAMyListPage is instantiated at the beginnig, it loads 10 rows from the DB, creates WAMyItem (WAComponent subclass) for every DB row and puts these WAMyItem instances to the WAMyListPage instance variable "items" (OrderedCollection) 3) WAMyListPage is rendered to the browser (render call on all WAMyItem "items" components) 4) User 1 clisks on the WAMyItem component from the rendered list (on the WAMyListPage) and goes into item detail page (detail page is not interesting here) 5) User 2 deletes 5 items/rows from the database (some way) 6) User 1 clicks browser back button and returns to the WAMyListPage, two cases can occur: A) typically, the "list page" is cached in the browser and browser immediatelly renders the list page from the cache - with all 10 old items (no refresh, broken old view with some non existing items) B) request from the browser to the Seaside app is made again (with old Seaside URL from browser history), then Seaside app just renders old state of WAMyListPage instance from the history and again - there is all 10 old WAMyItem items instantiated, so, broken again, old items in the view My question - where can I do a proper refresh of WAMyListPage list items? (manual refresh button in the Seaside app is unacceptable) Note: I can solve this by reloading WAMyListPage "items" instvar collection in every renderContentOn: (reload from DB, reload all WAMyItem instances) + instruct the browser to not cache any web page (in HTTP headers), so in point (6A) above, browser will ignore caching and make request to Seaside app again. In this way, everything works, WAMyListPage is actual every time, but main Seaside rule "Do not change state while rendering" is violated (WAMyItems are reinstantiated in every renderContentOn:). So, how do I face this? Thanks very much! pf

2 1

Updates to seaside.st?
by James Foster 13 Jan '18

13 Jan '18

There is a broken link at http://www.seaside.st/documentation/tutorials <http://www.seaside.st/documentation/tutorials> that I’d like to have fixed. The reference for my tutorial is to ‘gemstone.com’ and should be changed to ‘gemtalksystems.com’. Otherwise it is fine for now. Can someone help with that? Thanks, James Foster

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

seaside January 2018