Paul McNett wrote: > Carl Karsten wrote: >> Paul McNett wrote: >>> Ed, >>> >>> Can you remind me of the reason why biz.delete() must happen immediately >>> instead of waiting for biz.save(). And why biz.cancel() couldn't cancel >>> the pending deletions? >> So if you want to delete data, you need to save it? > > I think so, yes. Perhaps a prop setting in the bizobj could control the > behavior. > >> I think you are having flash backs to the days when deleting data didn't >> really >> delete it. > > Maybe. When calling sql delete, I expect the record to be gone for good > (unless I roll back the transaction, that is). Same for sql insert and > sql update. > > But I've also come to like working with bizobjs that cache the other > changes (sql update or sql insert isn't called until save(), so why > should delete() behave differently)? > >> > If this isn't something that we could put into Dabo, do you have >> > suggestions on how to implement this for my specific case? >> >> Set a flag. in your OK routine (what currently calls .save) call .delete >> for >> the flagged items. > > But all my logic is in the bizobj hierarchy. When the user chooses to > delete a subopening, we run bizSubopenings.delete(). When a different > routine is to draw the shutter, it gets drawn from the data in the > bizobj. I could add a flag, but it is another thing for my app to > maintain (remember to check the flag first) when I think this could be > implemented in Dabo for me to forget about.
i-layer, (mods to the framework that override the default behavior that are somehow don't collide with framework code updates.) which I never did figure out how it should be implemented. > >> > It still seems inconsistent that the other functions that modify the >> > dataset (new() and setFieldVal()) will cache the changes until save(), >> > while delete() must happen immediately without waiting for save(). >> > >> >> To me, .save and .delete operate at the same level: you can either save, or >> you >> can delete. once you have done either, you are done. so perfectly >> consistent. > > To me, .save() and .cancel() operate at the same level: you can either > save, or you can cancel. .new(), .delete(), and .setFieldVal() operate > at the same level (just like in SQL insert, delete, and update. So not > perfectly consistent. im confused. doesn't .save() cause the SQL INSERT or UPDATE commands? > > Read those threads I posted: you changed your tune! :) I claim being still in the VFP haze. glad I was unsure about it, this could have been extra embarrassing. Carl K _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
