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.
