Skip to Content
Last modified by Pascal Robert on 2010/09/19 10:31
From version 4.1
edited by Pascal Robert
on 2010/09/19 10:31
Change comment: There is no comment for this version
To version 5.1
edited by Pascal Robert
on 2010/09/19 10:31
Change comment: There is no comment for this version

Summary

Details

Page properties
Parent
... ... @@ -1,0 +1,1 @@
1 +Best Practices
Content
... ... @@ -21,7 +21,7 @@
21 21  
22 22  Depends on the application.
23 23  
24 -But most often, I am eating my cake and still having it by creating the EO first, but saving it into EC only when properly set up. That way, it can be wired up directly, and still, if the user abandons it, it just vanishes when the GC decides so :-)
24 +But most often, I am eating my cake and still having it by creating the EO first, but saving it into EC only when properly set up. That way, it can be wired up directly, and still, if the user abandons it, it just vanishes when the GC decides so
25 25  
26 26  === Geoff Hopson ===
27 27  
... ... @@ -29,11 +29,11 @@
29 29  
30 30  === Mike Schrag ===
31 31  
32 -Do most of you create the EO up-front and attach the form fields directly to the attributes of the EO, or do you clone the fields into the WOComponent and attach to those, then move them into a new EO in the "save" action? The problem with the first route is that if someone navigates away, you've got an empty EO inserted into the EC and the user doesn't realize that it's still sitting in their session, but it's obviously nicer because you can just wire up directly to the EO attributes and you don't have to keep the Component and the EO fields in-sync
32 +Do most of you create the EO up-front and attach the form fields directly to the attributes of the EO, or do you clone the fields into the WOComponent and attach to those, then move them into a new EO in the "save" action? The problem with the first route is that if someone navigates away, you've got an empty EO inserted into the EC and the user doesn't realize that it's still sitting in their session, but it's obviously nicer because you can just wire up directly to the EO attributes and you don't have to keep the Component and the EO fields in-sync
33 33  
34 34  === Jean-François Veillette ===
35 35  
36 -I use a new EO, in a 'peer' editingContext used for insertion/edition. That way, If changes are made to the eo, but not saved, and user change page, or even use the browser back button, I do not care, he doesn't screw-up the 'main' editingContext.
36 +I use a new EO, in a 'peer' editingContext used for insertion/edition. That way, If changes are made to the eo, but not saved, and user change page, or even use the browser back button, I do not care, he doesn't screw-up the 'main' editingContext.
37 37  
38 38  I forgot to mention another option that I used in some special situation :
39 -Instead of binding to an EO, bind to a NSMutableDictionary, then when you're ready to save, you can create your eo and apply the dictionary values to it (there is a method for that).
39 + Instead of binding to an EO, bind to a NSMutableDictionary, then when you're ready to save, you can create your eo and apply the dictionary values to it (there is a method for that).