...
Howard uses utility methods that convert from ServiceDef to ServiceDef2, adding a wrapper implementation around a ServiceDef instance if necessary:
Code Block |
public static ServiceDef2 toServiceDef2(final ServiceDef sd)
{
if (sd instanceof ServiceDef2)
return (ServiceDef2) sd;
return new ServiceDef2()
{
public boolean isPreventDecoration()
{
return false;
}
public ObjectCreator createServiceCreator(ServiceBuilderResources resources)
{
return sd.createServiceCreator(resources);
}
. . .
};
}
|
...
Use the complete version number of the release in which the type or method was added: i.e., @since 5.1.0.3.
Yes, at one time Howard used leading underscores for field names. He has since changed my mind, but this unfortunately infected other people; please try to make your code blend in when modifying existing source.
Long ago, Tapestry (3) code used the regrettable "leading-I-on-interfaces" style. Don't do that. Everything's an interfaceInstead, name the implementation class with an "Impl" at the end.
Howard prefers braces on a new line (and thus, open braces lined up with close braces), so that's what the default code formatting is set up for. It's okay to omit braces for trivial one-liner if statements, such as if (!test) return;
.
Indent with 4 spaces instead of tabs.
Use a lot of vertical whitespace to break methods into logical sections.
...
Try and keep the documentation up-to date as you make changes; it is much harder to do so later. This is now much easier using the Confluence wiki (you're reading the result ).
Documentation is was at one point the #1 criticism of Tapestry!
...