You are right. Both work.
I don't know what happenend, but now it works to me. So it was my fault
messing the code.
I'm very sorry.
El jueves, 3 de abril de 2014 21:55:59 UTC+2, Anthony escribió:
>
> Hmm, I have tried both methods (assigning a global variable and adding an
> attribute to "cur
Hmm, I have tried both methods (assigning a global variable and adding an
attribute to "current"), and in both cases it works fine (i.e., with the
callback defined and set in a model file and with the update happening in a
controller function). Perhaps you could attach a minimal app that
reprod
Sorry, i wanted to say 'model' not 'module'.
I've tried to pass data from a callback in a model to "its" function in a
controller with 'current', but was not able:
def my_before_callback():
from gluon import current
current._mydata = 'hello'
In a controller:
def my_function():
db..
On Thursday, April 3, 2014 10:58:32 AM UTC-4, mcamel wrote:
>
>
> Be careful about storing something in request.vars, as some other code may
depend on request.vars and end up failing due to it being changed.
>>>
>>> Any alternative you can suggest?. Session object seems error prone for
> Be careful about storing something in request.vars, as some other code may
>>> depend on request.vars and end up failing due to it being changed.
>>>
>>
>> Any alternative you can suggest?. Session object seems error prone for
>> this because of concurrency...
>>
>
> You could just declare a
>
> Be careful about storing something in request.vars, as some other code may
>> depend on request.vars and end up failing due to it being changed.
>>
>
> Any alternative you can suggest?. Session object seems error prone for
> this because of concurrency...
>
You could just declare a global v
Hello,
I've tried your suggestion and worked!. At 'before_update' stored old
>> values in request.vars using Set object, then at 'after_update' access
>> these values and compare to the new ones at f.
>>
>
> Be careful about storing something in request.vars, as some other code may
> depend on
>
> I've tried your suggestion and worked!. At 'before_update' stored old
> values in request.vars using Set object, then at 'after_update' access
> these values and compare to the new ones at f.
>
Be careful about storing something in request.vars, as some other code may
depend on request.var
Hello,
I've tried your suggestion and worked!. At 'before_update' stored old
values in request.vars using Set object, then at 'after_update' access
these values and compare to the new ones at f.
Note: if you use 'detect_record_change=True' it seems 'before_update' is
called twice, though it do
_after_update of course runs *after* the records have been updated in the
database, so if you use the Set to check those records in the _after_update
callback, they will therefore now have the new values. How could it be any
other way? Accessing the Set in the _after_update callback can still be
10 matches
Mail list logo
