21 May
2014
21 May
'14
11:05 a.m.
Hi,
A weirdness we had in our system was that the accessor called by a Magritte
description raised an Error. This code is called in a callback of a button:
[
aComponent
call:
(MatchInvestmentPage new
instruction: self;
yourself).
aComponent reset ]
on: Error
do: [ :err |
aComponent inform: err messageText.
aComponent answer ]
It tries to handle the error raised by "aComponent reset". The
MatchInvestmentPage component changes the state of the model of aComponent
(a magritte container component). The "aComponent reset" causes a magritte
MADescription (displaying a fairly simple amount field) to call an accessor
on the model, which raises the error.
We now removed this error handler and check for the error condition
elsewhere.
A broader question here is whether magritte descriptions should handle
exceptions when reading from the model (Object >> readUsing: which calls
#read: on).
Our understanding is that reading via accessors (MAAccessor
descendants) should not handle exceptions and a fallback (outer) handler
should handle it, because this is really unexpected. Is this right? Does
anyone know what the best way is to handle this situation?
Does it make sense to handle exceptions at the description level and
display a message to the user (on the field itself)? Not sure that it does,
but perhaps someone have better ideas here.
Thanks
Otto
PS. Does anyone have suggestions on nicer dialogs (the inform: call here)
that perhaps uses JQuery or another mechanism?
On Wed, May 21, 2014 at 10:45 AM, Otto Behrens <otto(a)finworks.biz> wrote:
Hi,
Pardon the delay on the response here. We decided to simplify the flow of
screens here to avoid the problem, in the light of a possibly complex way
that we're implementing the requirement and a pressing client.
But we'd like to explore this a bit more to see if we can find this
because it may be a problem elsewhere in our system or for someone else.
Firstly, we are using https://github.com/glassdb/Seaside30. The comment
says Seaside 3.0.7.1. I don't know how to figure out what version of
seaside this is besides trusting the comment. Looking at logs when loading
from scratch does not tell me much. How will I go about figuring out the
version that we've got loaded? From Johan's recent mail, I take it that
https://github.com/glassdb/Seaside31 could be good to upgrade to.
To get back to the problem, I think the continuation was created with
Scriptaculous >> lightbox: aComponent
^ self wait: [ :cc |
self
show: aComponent
onAnswer: cc
delegation: (SULightbox new
delegate: aComponent;
yourself).
WARenderNotification signal ]
Yes, we still have some Scriptaculous bits to get rid of, so if this is
the problem, the time is now.
What do you think? Is this it?
Thanks
Otto
On Tue, May 20, 2014 at 3:05 AM, Dale Henrichs <
dale.henrichs(a)gemtalksystems.com> wrote:
Otto,
Another possibility ... although I don't know if this kind of thing would
be possible but here goes nothing ...
If the callback that we're looking at with the broken stack was created
during WADispatchCallback>>evaluateWithArgument: or
WAMultiSelectTag>>triggerCallback and inform: answer was run in
WACallbackRegistry>>handle:, then the call back would have been created
with one less frame on the stack (no do: frame) ... and that would provide
us with a nice off by one error ...
some logging in the methods WADispatchCallback>>evaluateWithArgument: and
WAMultiSelectTag>>triggerCallback, where you record the oop of
theWACallback instance and logging in WACallbackRegistry>>handle:
recording the oops of WACallbacks run should rule this hare-brained idea
out or rule it right into play:) ...
Dale
On Mon, May 19, 2014 at 5:41 PM, Dale Henrichs <
dale.henrichs(a)gemtalksystems.com> wrote:
Otto,
I haven't been able to reproduce the bad error yet and I think that the
corruption is being caused by the previous callback in the set ... the
stack is corrupt at the point you try to create the continuation for the
inform: in the validation block ...
setting breakpoints in the WACallback>>evaluateWithFieldValues: will
catch the first callback in this sequence .. check to see if the stack
looks corrupt in the first call, then continue and see if the stack looks
corrupt before executing the code for the second callback ... if we can
isolate the transition from good stack to bad stack, we'll be on our way to
a solution...
I'm a bit suspicious of Magritte in the mix and the#reset message ... if
the structure of objects have been changed between the time the
continuation is created and the time it gets used, there might be trouble
... but I'm only grasping at straws at this point in time ... BTW, what
version of Seaside and Magritte are you using?
If Pieter's case is simpler, we might be able to figure it out easier
... I'd like to see the two addForm: methods:) Just in case something jumps
out at me...
Dale
On Mon, May 19, 2014 at 2:48 PM, Dale Henrichs <
dale.henrichs(a)gemtalksystems.com> wrote:
Otto,
Given an instance of WACallback, you can determine the source code of
the method where the callback is defined by looking at the `block` instance
variable og a WACallBack instance ... then in 3.1:
block _method sourceString. "source"
block _method inClass "class"
block _method _lineDeltaForBlock "line number in source (ignoring
selector)"
This can be done from a debugger (topaz) when error occurs ... navigate
up the stack to the WACallback>>evaluateWithFieldValues: frame... get the
oop of the _method (use `display oops`) and then sued the `send` command to
send the three different messages:
send @34379893 sourceString
... still digging ...
Dale
On Mon, May 19, 2014 at 10:55 AM, Otto Behrens <otto(a)finworks.biz>wrote;wrote:
> Thank you, Dale. I'm finally at home :)
>
>
> On Monday, May 19, 2014, Dale Henrichs <
> dale.henrichs(a)gemtalksystems.com> wrote:
>
>> Otto,
>>
>> Thanks!
>>
>> I'm finally in the office ) and will spend some time today getting
>> myself grounded in continuations again ... then I should have a better idea
>> how to proceed ...
>>
>> Dale
>>
>>
>> On Mon, May 19, 2014 at 9:47 AM, Otto Behrens <otto(a)finworks.biz>wrote;wrote:
>>
>>> > perhaps capturing the stack at the point the continue is created
>>> will give
>>> > us clues ...
>>>
>>> Attached are some stacks that I hacked in by calling the following
>>> method where we create them:
>>>
>>> WAPartialContinuation >> printStack
>>> | stream |
>>> stream := GsFile openWriteOnServer: '/tmp/stack_', self asOop
>>> printString.
>>> [ stream nextPutAll: partial printString ] ensure: [ stream close ]
>>>
>>> It does not tell me much at the moment. But perhaps you can see
>>> something. Or perhaps you have a better printing method that I can
>>> call?
>>>
>>> Thanks
>>> Otto
>>>
>>
>>