Changes for page Development-General Best Practices
Last modified by Pascal Robert on 2013/08/20 19:43
From version 7.1
edited by Pascal Robert
on 2010/09/13 00:36
on 2010/09/13 00:36
Change comment:
There is no comment for this version
To version 10.1
edited by Theodore Petrosky
on 2013/08/20 19:43
on 2013/08/20 19:43
Change comment:
Migrated to Confluence 5.3
Summary
-
Page properties (4 modified, 0 added, 0 removed)
Details
- Page properties
-
- Parent
-
... ... @@ -1,0 +1,1 @@ 1 +Best Practices - Author
-
... ... @@ -1,1 +1,1 @@ 1 -XWiki.p robert1 +XWiki.tedpet - Tags
-
... ... @@ -1,0 +1,1 @@ 1 +favourite - Content
-
... ... @@ -12,11 +12,11 @@ 12 12 13 13 It's both a common and a pernicious error. 14 14 15 -If you have WOConditionals, it's safest to bind them to booleans in your class file that you only change in appendToResponse, before it 's call to super.appendToResponse. If that is difficult, use whatever logic is natural in your program, but put a boolean (to which you bind your WOConditional) to reflect that logic before the super.appendToResponse, and only change the boolean accordingly at that point in that method.15 +If you have WOConditionals, it's safest to bind them to booleans in your class file that you only change in appendToResponse, before its call to super.appendToResponse. If that is difficult, use whatever logic is natural in your program, but put a boolean (to which you bind your WOConditional) to reflect that logic before the super.appendToResponse, and only change the boolean accordingly at that point in that method. 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>>url: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" shape="rect"]].]. In this latter page, pay close attention to the second to last paragraph. 20 20 21 21 == Creating WOComponents == 22 22 ... ... @@ -23,7 +23,6 @@ 23 23 Rather than use 24 24 25 25 {{code}} 26 - 27 27 MyNewPage nextPage = (MyNewPage)pageWithName("MyNewPage"); 28 28 29 29 {{/code}} ... ... @@ -31,17 +31,15 @@ 31 31 Prefer this form: 32 32 33 33 {{code}} 34 - 35 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.37 +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 43 43 {{code}} 44 - 45 45 @SuppressWarnings("unchecked") 46 46 public <T extends WOComponent> T pageWithName(Class<T> componentClass) { 47 47 return (T) super.pageWithName(componentClass.getName()); ... ... @@ -52,7 +52,6 @@ 52 52 which removes a cast: 53 53 54 54 {{code}} 55 - 56 56 MyNewPage nextPage = pageWithName(MyNewPage.class); 57 57 58 58 {{/code}} ... ... @@ -62,7 +62,6 @@ 62 62 KeyValueCoding (aka KVC) tends to encourage the use of constructs like this 63 63 64 64 {{code}} 65 - 66 66 website.addObjectToBothSidesOfRelationshipWithKey(newFolder, "folders"); 67 67 68 68 {{/code}} ... ... @@ -70,7 +70,6 @@ 70 70 This litters code with hard coded strings. Changing the property name breaks code with no compilation warnings. If you use EOGenerator to generate constants for the names: 71 71 72 72 {{code}} 73 - 74 74 public static final String FOLDERS = "folders"; 75 75 76 76 {{/code}} ... ... @@ -78,7 +78,6 @@ 78 78 You can use them in place of the hard coded strings and get errors when changes affect code: 79 79 80 80 {{code}} 81 - 82 82 website.addObjectToBothSidesOfRelationshipWithKey(newFolder, FOLDERS); 83 83 84 84 {{/code}} ... ... @@ -86,7 +86,6 @@ 86 86 An EOGenerator template (fragement) to do this: 87 87 88 88 {{code}} 89 - 90 90 public static final String ENTITY_NAME = "<$name$>"; 91 91 92 92 <$foreach propertyName classPropertyNames.@reversedArray do$> ... ... @@ -97,6 +97,6 @@ 97 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.//92 +* 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>>WO :EOF-Using EOF-EOGenerator]] page for more similar tricks.94 +See the [[EOGenerator>>doc:WO.EOF-Using EOF-EOGenerator]] page for more similar tricks.