Changes for page Development-WOForm Best Practices

Summary

• Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-Programming__WebObjects-Web Applications-Development-WOForm Best Practices
	1	+Web Applications-Development-WOForm Best Practices

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.smmccraw
	1	+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