Skip to Content
Last modified by Pascal Robert on 2013/08/20 19:43
From version 5.1
edited by Quinton Dolan
on 2007/07/12 20:13
Change comment: There is no comment for this version
To version 7.1
edited by Pascal Robert
on 2010/09/13 00:36
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Programming__WebObjects-Web Applications-Development-General Best Practices
1 +Development-General Best Practices
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.qdolan
1 +XWiki.probert
Content
... ... @@ -1,4 +1,4 @@
1 -== Avoid Changing WOComponent Structure Before It Is Used ==
1 +== Avoid Changing WOComponent Structure Before It Is Used ==
2 2  
3 3  One of the more pernicious problems that afflict new WebObjects developers results from creating and sending out a WOComponent in appendToResponse, then changing the structure of that component before the subsequent takeValuesFromRequest and invokeAction methods have completed on that page.
4 4  
... ... @@ -16,15 +16,15 @@
16 16  
17 17  If you have WORepetitions, confirm that none of your code changes the sizes of those arrays or indexes on which their sizes depend between your activation of super.appendToResponse and the completion of the corresponding invokeAction for that page.
18 18  
19 -For a deeper explanation of this process and its ramifications, see [[In particular, read the last paragraph, and the following page ~[DevGuide-WOClasses>>http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/WOClasses21.html||title="http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/WOClasses20.html"]].]. In this latter page, pay close attention to the second to last paragraph.
19 +For a deeper explanation of this process and its ramifications, see In particular, read the last paragraph, and the following page [[DevGuide-WOClasses>>http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/WOClasses21.html||title="http://developer.apple.com/documentation/LegacyTechnologies/WebObjects/WebObjects_4.5/System/Documentation/Developer/WebObjects/DevGuide/WOClasses20.html"]].. In this latter page, pay close attention to the second to last paragraph.
20 20  
21 -== Creating WOComponents ==
21 +== Creating WOComponents ==
22 22  
23 23  Rather than use
24 24  
25 25  {{code}}
26 26  
27 -MyNewPage nextPage = (MyNewPage)pageWithName("MyNewPage");
27 +MyNewPage nextPage = (MyNewPage)pageWithName("MyNewPage");
28 28  
29 29  {{/code}}
30 30  
... ... @@ -32,11 +32,11 @@
32 32  
33 33  {{code}}
34 34  
35 -MyNewPage nextPage = (MyNewPage)pageWithName(MyNewPage.class.getName());
35 +MyNewPage nextPage = (MyNewPage)pageWithName(MyNewPage.class.getName());
36 36  
37 37  {{/code}}
38 38  
39 -The class.getName() allows Eclipse to do proper refactoring and you can right click=>References=>Workspace your class and truly find all the references vs just having a string references. One other advantage that it has is that if you have two pages with the same name but in different packages, this avoids confusion. If you just use pageWithName("MyNewPage";), WO can return the wrong one. Minor change but really nice benefits.
39 +The class.getName() allows Eclipse to do proper refactoring and you can right click=>References=>Workspace your class and truly find all the references vs just having a string references. One other advantage that it has is that if you have two pages with the same name but in different packages, this avoids confusion. If you just use pageWithName("MyNewPage";-) , WO can return the wrong one. Minor change but really nice benefits.
40 40  
41 41  If you use 1.5, you can use the 1.5 variation:
42 42  
... ... @@ -57,13 +57,13 @@
57 57  
58 58  {{/code}}
59 59  
60 -== Avoid String Literals ==
60 +== Avoid String Literals ==
61 61  
62 62  KeyValueCoding (aka KVC) tends to encourage the use of constructs like this
63 63  
64 64  {{code}}
65 65  
66 -website.addObjectToBothSidesOfRelationshipWithKey(newFolder, "folders");
66 +website.addObjectToBothSidesOfRelationshipWithKey(newFolder, "folders");
67 67  
68 68  {{/code}}
69 69  
... ... @@ -71,7 +71,7 @@
71 71  
72 72  {{code}}
73 73  
74 -public static final String FOLDERS = "folders";
74 +public static final String FOLDERS = "folders";
75 75  
76 76  {{/code}}
77 77  
... ... @@ -79,7 +79,7 @@
79 79  
80 80  {{code}}
81 81  
82 -website.addObjectToBothSidesOfRelationshipWithKey(newFolder, FOLDERS);
82 +website.addObjectToBothSidesOfRelationshipWithKey(newFolder, FOLDERS);
83 83  
84 84  {{/code}}
85 85  
... ... @@ -88,17 +88,15 @@
88 88  {{code}}
89 89  
90 90  public static final String ENTITY_NAME = "<$name$>";
91 -
91 +
92 92  <$foreach propertyName classPropertyNames.@reversedArray do$>
93 - public static final String <$propertyName.uppercaseString$> = "<$propertyName$>";<$endforeach do$>
93 + public static final String <$propertyName.uppercaseString$> = "<$propertyName$>";<$endforeach do$>
94 94  
95 95  {{/code}}
96 96  
97 -=== Except ===
97 +=== Except ===
98 98  
99 99  * This does not address the related issue when property names are used in bindings in a wod file
100 -* This does not work in the (admittedly rare) case where one class implements multiple entities. EOGenerator assumes one entity == one class. So, MyEO.ENTITY//NAME will return the name of the last entity to get generated. //
100 +* This does not work in the (admittedly rare) case where one class implements multiple entities. EOGenerator assumes one entity == one class. So, MyEO.ENTITY//NAME will return the name of the last entity to get generated.//
101 101  
102 -See the [[EOGenerator>>Programming__WebObjects-EOF-Using EOF-EOGenerator]] page for more similar tricks.
103 -
104 -Category:WebObjects
102 +See the [[EOGenerator>>WO:EOF-Using EOF-EOGenerator]] page for more similar tricks.