Page History

...

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 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.

...

Rather than use

MyNewPage nextPage = (MyNewPage)pageWithName("MyNewPage");

Prefer this form:

MyNewPage nextPage = (MyNewPage)pageWithName(MyNewPage.class.getName());

...

If you use 1.5, you can use the 1.5 variation:

@SuppressWarnings("unchecked")
public <T extends WOComponent> T pageWithName(Class<T> componentClass) {
  return (T) super.pageWithName(componentClass.getName());
}

which removes a cast:

MyNewPage nextPage = pageWithName(MyNewPage.class);

...

KeyValueCoding (aka KVC) tends to encourage the use of constructs like this

website.addObjectToBothSidesOfRelationshipWithKey(newFolder, "folders");

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:

public static final String FOLDERS = "folders";

You can use them in place of the hard coded strings and get errors when changes affect code:

website.addObjectToBothSidesOfRelationshipWithKey(newFolder, FOLDERS);

An EOGenerator template (fragement) to do this:

public static final String ENTITY_NAME = "<$name$>";

<$foreach propertyName classPropertyNames.@reversedArray do$>
  public static final String <$propertyName.uppercaseString$> = "<$propertyName$>";<$endforeach do$>

...