Hey, helping a friend with his blog at: http://www.morphle.com:8204
and he's noticed that sometimes, when he goes to a specific blog entry,
he enters the page at the top and sometimes at the bottom. Is this a
random behavior or based on some cookie that is set or...?
Thanks,
Lawson
When I use +audio+ to refer to an audio file int he library, it
displays a QuickTime control widget. When I refer to the audio using a
url, +http://www.myserver.com/audio.mp3+, it just shows the link,
which opens a new window when I click on it.
Is there any way to get an inline auido control widget for an external file?
Thanks,
Lawson
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
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
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
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
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
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
