Hi Michael, It s also confusing for the user if you delete validation error messages sometimes on client side and sometimes not.
I prefer existing solution, cause it s the common case. -- Volker On 12 Mrz., 18:01, Michael Latta <[email protected]> wrote: > In this case when a row is deleted from the subform the messages should be > deleted. It is confusing to users. Having the JavaScript do more to present a > consistent view including validations would improve things for users. This is > a special case where the JavaScript could clean up, but doing it in all cases > I agree would be a big deal. The form could be submitted just for validation > at points in the workflow to update messages, such as when a subform record > is deleted or added. > > I often wonder if the as approach of saving up all the changes and submitting > them all at once is best. If we had finer grained ui some issues would be > resolved. If forms were more like live to the db than batch updates would be > made ongoingly and subform records created as they were entered. Too much of > a change for the near term of course, and likely to never happen. But, an > interesting thought exercise. > > Michael > > Sent from my iPad > > On Mar 12, 2011, at 6:30 AM, vhochstein <[email protected]> wrote: > > > Hi, > > > Well, that s just the way validation error messaging is work... > > > If you ve got an validation error it will stay there until you > > resubmit the form. > > You cannot remove errors on client side, cause only server performs > > validation. > > > -- > > Volker > > > On Mar 9, 6:15 pm, "Sergio Cambra .:: entreCables S.L. ::." > > <[email protected]> wrote: > >> On Miércoles, 9 de Marzo de 2011 18:04:15 Michael Latta escribió: > > >>> They reported several cases, some I have not recreated yet. > > >>> The one I have recreated is as follows: > > >>> Edit a record with a subform for a one to many association. > >>> Create a new record in the subform that fails validation. > >>> Submit the form and get errors on the subform and the main form. > >>> Delete the row in the subform that was in error, note the error message is > >>> still there. > > >> If the subform is horizontal (default subform) error are in a different > >> tr, so > >> we should add JS to remove previous tr when is a tr with error messages. > >> With > >> a vertical subform it works better. > > >>> Michael > > >>> On Mar 9, 2011, at 8:26 AM, Sergio Cambra .:: entreCables S.L. ::. wrote: > >>>> On Miércoles, 9 de Marzo de 2011 16:22:24 Michael Latta escribió: > >>>>> My users are complaining about error messages left in the page after a > >>>>> clean update. Has anyone tackled cleaning up error messages? Is there > >>>>> a reason not to remove error messages prior to a new submit? Because > >>>>> child record errors are disconnected from the records they linger, the > >>>>> same appears to be the case for top level errors related to child > >>>>> records. > > >>>>> Michael > > >>>> I don't know what error messages left are you talking about > > >> -- > >> 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 > > athttp://groups.google.com/group/activescaffold?hl=en. > > -- 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.
