On Lunes, 14 de Febrero de 2011 07:22:59 Michael Latta escribió: > I have blank rows off so that may be the problem. The code is not > accounting for that setting so the one with errors which happens to be at > the end is being locked. When I disable that test it works as expected > (other than leaving the messages behind when it is deleted).
With blank rows disabled, locked should be nil, because locked = associated.last is skipped. Maybe locked should be set to nil when blank rows is disabled. Can you add this? else locked = nil below this line: locked = associated.last > > Michael > > On Feb 9, 2011, at 9:11 AM, Sergio Cambra .:: entreCables S.L. ::. wrote: > > On Miércoles, 9 de Febrero de 2011 17:02:29 Michael Latta escribió: > >> The problem is when a user attempts to add a record, and then submits > >> with errors. That "blank" record is not blank and the user has no way > >> to clear it to get a submit to complete. Even clearing all visible > >> fields does not clear the child record errors in all cases. > > > > Locked should be set to a actual blank record, not a record with errors: > > associated << column.association.klass.new > > locked = associated.last > > > > So locked is always set to a new blank record, not a submitted record. > > Also, locked is only used to set a class to apply some CSS styles. Is it > > locked really the problem? I can't try it now. > > > >> Michael > >> > >> On Feb 9, 2011, at 1:44 AM, Sergio Cambra .:: entreCables S.L. ::. wrote: > >>> On Martes, 8 de Febrero de 2011 16:51:28 Michael Latta escribió: > >>>> In the subform partial there is a render with locals setting :locked > >>>> to a computed value. I changed that to "false" so it would allow the > >>>> delete at all times. > >>> > >>> Locked is set to the blank record which is added by default at bottom, > >>> so that's the only record which should be locked. > >>> > >>> Can you send that computed value? Maybe it was changed and you have an > >>> old version. > >>> > >>>> Michael > >>>> > >>>> On Feb 8, 2011, at 1:26 AM, Sergio Cambra .:: entreCables S.L. ::. wrote: > >>>>> On Domingo, 6 de Febrero de 2011 22:36:09 Michael Latta escribió: > >>>>>> Why are the association-record-errors placed as a DIV at the same > >>>>>> level as the ol entries for each record, rather than being at the > >>>>>> top of the ol for the record with the error? > >>>>>> > >>>>>> My users reported a usability problem with creating a record that > >>>>>> had validation errors: > >>>>>> > >>>>>> 1) create a new record > >>>>>> 2) filling invalid data > >>>>>> 3) submit > >>>>>> 4) errors are returned but the new record can not be deleted to get > >>>>>> a clean submit. > >>>>>> > >>>>>> Item 4 above seems wrong to me. In digging around the code I found > >>>>>> where it explicitly prevents the last record if new from being > >>>>>> deleted. Users should be able to scrap a new record with errors. If > >>>>>> I remove the locked logic I can delete the record but the errors > >>>>>> remain. If they were rendered within the ol then it would clean > >>>>>> them up when the ol was removed. > >>>>> > >>>>> I have moved errros inside the ol, but it's only possible in vertical > >>>>> subform, is not possible in horizontal subform because errors and > >>>>> record are in different tr. > >>>>> > >>>>> What logic did you change to remove the record? -- Sergio Cambra .:: entreCables S.L. ::. Mariana Pineda 23, 50.018 Zaragoza T) 902 021 404 F) 976 52 98 07 E) [email protected] -- You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" 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/activescaffold?hl=en.
