Yarek Kowalik <[EMAIL PROTECTED]> writes: > I am not familiar with your write-delayed-p patch. I'll search the > group archive to see if I can find it. > > The pre-validate and pre-persist changes allow me to have a finer > grain control over the process of saving data from the form widget. > This allows me to persist changes to related data activated in > neighboring and related widgets in pre-persist callback first, and > then continue to persist the form data if pre-persist is successfull. > All this is wrapped in a transaction, so it's an all-or-nothing > operation.
Thanks for the explanation. Our patches serve different purposes. Mine was specifically to delay calling the slot writer, which failed for many-to-many relationships if the object hasn't been persisted yet. You can't have many-to-many relationships with integrity constraints in weblocks without this patch. There is more about it at the URL I provided. In my tree, I merged both patches. --J. > On Dec 8, 1:03 pm, Jan Rychter <[EMAIL PROTECTED]> wrote: >> While merging my stuff with modern-dispatching things bombed out and I >> discovered that someone (Yarek?) might have been trying to solve the >> same problem I encountered, described here: >> >> http://groups.google.com/group/weblocks/browse_thread/thread/f18cc32d... >> >> My write-delayed-p patch never got pulled into weblocks somehow. >> >> I can't quite understand the intent of pre-validate and pre-persist >> options -- was the goal same as mine? >> >> --J. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" 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/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
