smallwiki August 2010

smallwiki@list.inf.unibe.ch

8 participants
29 discussions

by Reza Razavi

At 10:58 26/08/2010, Nick Ager wrote: >So what to do? Should I back out the change? As Lukas suggested, it would be useful to give it a try, if possible in real test conditions involving end-users, to gain a better idea of the real risks, at least in your own app's config. Regards, Reza

14 years, 3 months

Re: PRContentsWidget swallowing errors

by Reza Razavi

At 10:33 26/08/2010, Nick Ager wrote: >is there a problem changing WAWalkbackErrorHandler to something that >makes more sense to the end user? Seaside provides general mechanisms. More specific solutions depend on the end-user community that one targets. In my experience, I had happy end-users with a simple dialog box asking their agreement to communicate their execution stack, knowing that that context may contain proprietary information. Regards, Reza

14 years, 3 months

Re: PRContentsWidget swallowing errors

by Reza Razavi

At 09:36 26/08/2010, Nick Ager wrote: >were silently consumed (the errors weren't displayed) by >PRContentsWidget's error handling and felt that this wasn't the >intention of the original code. To me, the intention of the original code has for sure not been to hide errors, but to provide a handy solution to capture unexpected errors. This method is the "heart" of the Pier's request interpreter ("eval"), and in that sense it seems well situated for processing those exceptions. Of course, there is room for fine tuning, but my understanding is that Pier has invested in avoiding such programming errors. Still, Pier is an extendable system and in that sense responsible for handling eventual errors in plug-ins. Error instead of MAError may be also explained in this way. >In the case you mention, where 'Pier keeps handling requests >gracefully' would the errors make any sense to the user and could >they take remedial action to correct the error? No, programming errors don't, in general, make sense to end-users. Remedial measures could be taken if the error is related to end-user actions. For example, feeding unexpected content (not only by Pier, but also by its plug-ins). But in all cases, for end-users it seems better to have an application that keeps responsive, eventually with meaningful error messages, instead of a *wall back* window. Regards, Reza

14 years, 3 months

Re: PRContentsWidget swallowing errors

by Reza Razavi

At 11:02 25/08/2010, Nick Ager wrote: >I've noticed that non-validation errors are trapped by the code in >PRContentsWidget>>#onAnswerCommand: aCommand Hi Nick, You have certainly also noticed that this is a key method in the Pier's request handling process. In my experience, and just from a practical point of view, I found it useful for "production" images to have here Error instead of MAError, since even in case of an unexpected error, Pier keeps handling requests gracefully, while rendering the error message on the client side. For development images, it would be sufficient to add a 'halt' inside the exception handling block. I should add that, in practice, I've encountered rarely such cases, and, as far as I remember, those cases have always been related to my own add-ons. Nevertheless, it seems hard to definitely assess that during the execution of ALL commands, in ALL end-user use cases, the exceptional situations will strictly be limited to validation errors. If this makes sense, then Error would be a better choice. Regards, Reza

14 years, 3 months

PRContentsWidget swallowing errors

by Nick Ager

Hi, I've noticed that non-validation errors are trapped by the code in PRContentsWidget>>#onAnswerCommand: aCommand Can anyone anticipate any problems catching MAError rather than Error, so that non-validation errors are propagated as normal and validation errors are displayed. Currently the code reads: onAnswerCommand: aCommand aCommand isNil ifTrue: [ ^ self context: (self context structure: self context structure) ]. [ aCommand execute ] on: Error do: [ :err | ^ self component errors add: err ]. self context: aCommand answer I'd like to change Error to MAError Have I missed anything? Nick

14 years, 3 months

test message

by Lawson English

this hist has been quiet lately. So just checking to see if the server is working. Lawson

14 years, 3 months

can't load Gallery addon because I can't load Rio

by Lawson English

The Gallery addon for pier first requires that Rio be installed. http://www.squeaksource.com/@7zePIlRlfoA0dT1I/VwzOlsoy However, rio won't install due to errors: FileMacOSXExectuive class as yet unclassified getenv: getenv: varString " self getenv: 'HOME' " " self getenv: 'ZYZZYX' " <> expected ->cdecl: char* 'getenv' ( char* ) module: 'libc.dylib'> ^self externalCallFailed Not sure how to fix this... Using the Seaside-3.0rc one-click for Pharo-Seaside Lawson

14 years, 4 months

environment copy strangeness in pier on seaside 3.0rc one-click install

by Lawson English

I was trying to make a copy of my enviornment template in Pier using the seaside 3.0rc oneclick available from squeak.org The steps I took: login. click on +system click on _environment select the copy command and name it environmentcopy save create a new page. click settings. Point the environment to /system/templates/environmentcopy (have to manually enter that since "choose" doesn't work as I expected) save start editing /system/templates/environmentcopy. it saves the changes in the original environment page. Is this normal behavior? I thought copy meant copy contents, not just create a new link to the same file. Lawson

14 years, 4 months

Inline http or html page?

by Lawson English

How do I embed raw http in a pier page, or embed an external page? +http://www.google.com+ doesn't work. Lawson

14 years, 4 months

Optimizing PRViewCommand >> label

by Reza Razavi

At 09:29 18/08/2010, Lukas Renggli wrote: >I already committed a patch :-) Impressive; thanks! Just in case you would still have some time to devote, a similar case is "PRViewCommand >> label", which is in particular often called by "WAAnchorTag >> goto:" An alternative would be: PRViewCommand >> label ^ self viewComponentClass labelIn: self context Which would imply for example: PRDefaultView class >> labelIn: aContext ^ aContext structure title And eventually: PRDefaultView >> label ^ self class labelIn: sel context In the "worth" case, the class would instantiate itself to compute its label. That could though break the plug-ins that depend on the current behavior. Regards, Reza

14 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

smallwiki August 2010