Child pages
  • Development-General Best Practices

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Code Block

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

Prefer this form:

Code Block

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

...

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

Code Block

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

which removes a cast:

Code Block

MyNewPage nextPage = pageWithName(MyNewPage.class);

...

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

Code Block

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:

Code Block

public static final String FOLDERS = "folders";

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

Code Block

website.addObjectToBothSidesOfRelationshipWithKey(newFolder, FOLDERS);

An EOGenerator template (fragement) to do this:

Code Block

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

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

...