Errors not shown after AJAX form submit

44 views
Skip to first unread message

Adam Warski

unread,
Jan 4, 2010, 3:10:13 PM1/4/10
to Lift
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

Ross Mellgren

unread,
Jan 4, 2010, 3:14:22 PM1/4/10
to lif...@googlegroups.com
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

> --
>
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
> .
>
>

Adam Warski

unread,
Jan 5, 2010, 2:37:51 AM1/5/10
to lif...@googlegroups.com
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

Marius

unread,
Jan 5, 2010, 3:00:43 AM1/5/10
to Lift
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.

Br's,
Marius

> >> For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en

Adam Warski

unread,
Jan 5, 2010, 7:10:50 AM1/5/10
to lif...@googlegroups.com
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

Naftoli Gugenheim

unread,
Jan 5, 2010, 9:31:02 AM1/5/10
to ad...@warski.org, lif...@googlegroups.com
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

unread,
Jan 5, 2010, 9:38:49 AM1/5/10
to lif...@googlegroups.com
Ah so it's treated as a new request each time.
Clear now, thanks :)

Adam

Ross Mellgren

unread,
Jan 5, 2010, 10:14:51 AM1/5/10
to lif...@googlegroups.com
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

>>> 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 lif...@googlegroups.com.
>> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com
>> .

>> 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 lif...@googlegroups.com.
>> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com
>> .

>> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en

Reply all
Reply to author
Forward
0 new messages