Avoid Changing WOComponent Structure Before It Is Used
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.
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|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.
Rather than use
MyNewPage nextPage = (MyNewPage)pageWithName("MyNewPage");
MyNewPage nextPage = pageWithName(MyNewPage.class);
Avoid String Literals
KeyValueCoding (aka KVC) tends to encourage the use of constructs like this
public static final String ENTITY_NAME = "<$name$>"; <$foreach propertyName classPropertyNames.@reversedArray do$> public static final String <$propertyName.uppercaseString$> = "<$propertyName$>";<$endforeach do$>
- This does not address the related issue when property names are used in bindings in a wod file
- 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.
See the EOGenerator page for more similar tricks.