[Glass] callbackMarker not found in Seaside stack

Wed May 21 02:05:33 PDT 2014

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 at 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 at 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 at 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 at 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 at finworks.biz>wrote:
>>>>
>>>>> Thank you, Dale. I'm finally at home :)
>>>>>
>>>>>
>>>>> On Monday, May 19, 2014, Dale Henrichs <
>>>>> dale.henrichs at 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 at finworks.biz>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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140521/879a83f2/attachment-0001.html>