Changes for page Development-WOForm Best Practices
Last modified by Pascal Robert on 2010/09/19 10:31
From version 2.1
edited by smmccraw
on 2007/07/08 09:46
on 2007/07/08 09:46
Change comment:
There is no comment for this version
To version 3.1
edited by Pascal Robert
on 2007/09/03 17:02
on 2007/09/03 17:02
Change comment:
There is no comment for this version
Summary
-
Page properties (3 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 - Programming__WebObjects-WebApplications-Development-WOForm Best Practices1 +Web Applications-Development-WOForm Best Practices - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki. smmccraw1 +XWiki.probert - Content
-
... ... @@ -1,6 +1,6 @@ 1 -== Attaching EO's to a Form 1 +== Attaching EO's to a Form == 2 2 3 -=== Pierre Bernard 3 +=== Pierre Bernard === 4 4 5 5 I do create the EO and insert it into an editing context dedicated to the task of creating and eventually saving that EO. That editing context is peer to the default editing context. Actually all my edits happen in dedicated peer contexts. The session default is used for reads only. This eliminates the risk of having a pending change hang around. 6 6 ... ... @@ -17,25 +17,23 @@ 17 17 * I do not lose precision on a value which internally had a higher precision than what the form shows 18 18 * I handle parsing exceptions in code. For one this allows keeping the unparsable value in the form 19 19 20 -=== Ondra Cada 20 +=== Ondra Cada === 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 -=== Geoff Hopson 26 +=== Geoff Hopson === 27 27 28 28 I find it much cleaner to have a formValues NSMutableDictionary and have the key names the same as my EO attribute names. In my WOD file I can bind text field values etc. to 'formValues.myAttribute. It also allows me to preset some defaults, hide any hidden fields I may need, stuff like that. I can then easily blat the dictionary into an inserted EO once I am pretty happy with the data that has been collected. 29 29 30 -=== Mike Schrag 30 +=== Mike Schrag === 31 31 32 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 -=== Jean-François Veillette 34 +=== Jean-François Veillette === 35 35 36 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 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). 40 - 41 -Category:WebObjects