Well, not exactly. RequestVar is per-logical-request, which means it  
will be automatically restored to whatever value it had during the  
original HTTP request on any "related" HTTP request, that is, AJAX  
calls.

-Ross

On Jan 5, 2010, at 9:38 AM, Adam Warski wrote:

> Ah so it's treated as a new request each time.
> Clear now, thanks :)
>
> Adam
>
> On Jan 5, 2010, at 3:31 PM, Naftoli Gugenheim wrote:
>
>> I don't know the exact reason, but the parameter to the RequestVar  
>> constructor is a call by name, which means it's a function that can  
>> be re-evaluated. Normally this value is recalculated at the start  
>> of each request. In any case its seems that in your case they're  
>> being recalculated and restored to before you modified them.  
>> However in the first case that means referencing a variable that  
>> holds the change.
>>
>> -------------------------------------
>> Adam Warski<[email protected]> wrote:
>>
>> Hello,
>>
>>> I think the difference is in showAll scope. It was implemented for  
>>> non
>>> Ajax context (just for msgs snippet) but it wasn't implemented for
>>> Ajax (as far as I can tell).
>>>
>>> Ajax notices (if there are any) are appended to user's JsCmd  
>>> response.
>>> But this code has no idea about the showAll snippet attribute.
>>> Therefore ajax notices that are associates with an ID will not be
>>> shown in <lift:Msgs showAll="true"/> 's real estate.
>>>
>>> Please open a defect for this.
>> I think I more or less understand :)
>> Here's the defect: http://github.com/dpp/liftweb/issues/#issue/271
>>
>> By the way, do you have any idea why my example application  
>> produces such weird results?
>> I looked in the RequestVar code and didn't find anything there that  
>> would make it behave differently in the two scenarios.
>>
>> Adam
>>
>>
>>> Br's,
>>> Marius
>>>
>>> On Jan 5, 9:37 am, Adam Warski <[email protected]> wrote:
>>>> Hello,
>>>>
>>>> Ah, I didn't spot this. I only have:
>>>>
>>>> <lift:Msgs showAll="true"/>
>>>>
>>>> which would suggest that it should show all errors.
>>>> And anyway, why does it work then with normal form submit, and  
>>>> doesn't with ajax form submit?
>>>>
>>>> Adam
>>>>
>>>> On Jan 4, 2010, at 9:14 PM, Ross Mellgren wrote:
>>>>
>>>>> S.error(NodeSeq) and S.error(List[FieldError]) differ in that the
>>>>> latter registers errors against particular fields, and the  
>>>>> former is a
>>>>> page-wide error. The latter is more like S.error(String,  
>>>>> NodeSeq). Do
>>>>> you have Msg snippets for each field, like this?
>>>>
>>>>> ... field ... <lift:msg id="my_field_id" />
>>>>
>>>>> (see net.liftweb.builtin.snippet.Msg for a better example)
>>>>
>>>>> Hope that helps,
>>>>> -Ross
>>>>
>>>>> On Jan 4, 2010, at 3:10 PM, Adam Warski wrote:
>>>>
>>>>>> Hello,
>>>>
>>>>>> investigating further making the tutorial form submittable with
>>>>>> ajax, I found some weird behavior; I'm using 1.1-M8.
>>>>
>>>>>> It seems that when the form is submitted with ajax, and there are
>>>>>> form validation errors, the error is not shown. However, the  
>>>>>> notices
>>>>>> work fine. So:
>>>>>> - S.notice("Added "+todo.desc); shows the notice after the ajax  
>>>>>> form
>>>>>> submit
>>>>>> - S.error(xs); doesn't, only if the form is submitted in the  
>>>>>> regular
>>>>>> way
>>>>
>>>>>> I didn't manage to find the problem yet, but if instead of  
>>>>>> calling
>>>>>> S.error(xs); I do:
>>>>>> xs.map {i => S.error(i.msg) };
>>>>>> the error is shown.
>>>>
>>>>>> The error(n: NodeSeq)  and error(vi: List[FieldError]) don't  
>>>>>> seem to
>>>>>> differ a lot, but there must be something special about the  
>>>>>> second.
>>>>
>>>>>> I tried to reproduce the problem using a simple application, but
>>>>>> there I found  another strange thing.
>>>>>> The app is:
>>>>
>>>>>> object Test {
>>>>>> def main(args: Array[String]) {
>>>>>> val z = new ListBuffer[String]
>>>>>> object x extends RequestVar(z)
>>>>>> x += "a"
>>>>
>>>>>> object y extends RequestVar(new ListBuffer[String])
>>>>>> y += "b"
>>>>
>>>>>> println(x.is)
>>>>>> println(y.is)
>>>>>> }
>>>>>> }
>>>>
>>>>>> and prints out:
>>>>>> ListBuffer(a)
>>>>>> ListBuffer()
>>>>
>>>>>> so for some reason, if the initial value of the RequestVar is  
>>>>>> passed
>>>>>> without an intermediate val, the list content isn't modified.
>>>>>> But it could be that I'm using the RequestVar outside of it's
>>>>>> intended environment which may be the cause ;).
>>>>
>>>>>> --
>>>>>> Adam
>>>>
>>>>>> --
>>>>
>>>>>> You received this message because you are subscribed to the  
>>>>>> Google
>>>>>> Groups "Lift" group.
>>>>>> To post to this group, send email to [email protected].
>>>>>> To unsubscribe from this group, send email to 
>>>>>> [email protected]
>>>>>> .
>>>>>> For more options, visit this group 
>>>>>> athttp://groups.google.com/group/liftweb?hl=en
>>>>>> .
>>>>
>>>>> --
>>>>
>>>>> You received this message because you are subscribed to the  
>>>>> Google Groups "Lift" group.
>>>>> To post to this group, send email to [email protected].
>>>>> To unsubscribe from this group, send email to 
>>>>> [email protected] 
>>>>> .
>>>>> For more options, visit this group 
>>>>> athttp://groups.google.com/group/liftweb?hl=en 
>>>>> .
>>>
>>> --
>>>
>>> You received this message because you are subscribed to the Google  
>>> Groups "Lift" group.
>>> To post to this group, send email to [email protected].
>>> To unsubscribe from this group, send email to 
>>> [email protected] 
>>> .
>>> For more options, visit this group at 
>>> http://groups.google.com/group/liftweb?hl=en 
>>> .
>>>
>>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google  
>> Groups "Lift" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to 
>> [email protected] 
>> .
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en 
>> .
>>
>>
>> --
>>
>> You received this message because you are subscribed to the Google  
>> Groups "Lift" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to 
>> [email protected] 
>> .
>> For more options, visit this group at 
>> http://groups.google.com/group/liftweb?hl=en 
>> .
>>
>>
>
> --
>
> You received this message because you are subscribed to the Google  
> Groups "Lift" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to 
> [email protected] 
> .
> For more options, visit this group at 
> http://groups.google.com/group/liftweb?hl=en 
> .
>
>

--

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en.


Reply via email to