On Sat, Mar 13, 2010 at 1:16 AM, Igor Drobiazko <[email protected]> wrote: > I prefer the Messages object approach over String.format because the later > bloats the code in case of detailed messages. In some cases this leads to > catch blocks that are longer then the corresponding try block. A descriptive > method name of the Messages object looks better but I don't mind to switch > to String.format inside service imlementation classes.
Or the method that generates that exception message string could be an additional method of the same class, which gives you the same benefit. My personal coding style is always evolving; I recently read Uncle Bob's "Clean Code" book, and I've been making some changes because of it (more smaller methods with longer descriptive names). > > On Fri, Mar 12, 2010 at 6:27 PM, Howard Lewis Ship <[email protected]> wrote: > >> If you've been following my code changes, you may have noticed that >> I've abandoned the use of the Messages object for generating service >> layer messages. >> >> I started using the Messages approach in Tapestry 4 & HiveMind, which >> were written before Java 5 was available. I didn't want to have lots >> of ugly string building code in my service implementations, and I >> hoped that having the messages in an external properties file would >> lead to better consistency of error messages. >> >> I carried this forward into Tapestry 5, more out of habit than serious >> consideration. >> >> However, Tapestry 5 is based on JDK 1.5 which does have >> String.format(). That takes most of the string out of writing the >> error messages. >> >> Live service implementation reloading affects this picture as well; >> I've had to take some of these classes (such as ServicesMessages) and >> make them public, not package private, due to class loader issues with >> reloaded classes. >> >> So, on the whole, I don't bother with using Messages for service-layer >> messages ... I don't like having to have three files open >> (.properties, ServicesMessages, and the actual service >> implementation). I don't find it likely we'll ever translate the >> messages into another locale. I like being able to see exactly what my >> error messages look like, and I like being able to quickly recompose >> them without fear of unforeseen consequences. >> >> I've noticed that others have been sticking with the Messages approach >> ... is that out of habit as well, or more purposeful? >> >> -- >> Howard M. Lewis Ship >> >> Creator of Apache Tapestry >> >> The source for Tapestry training, mentoring and support. Contact me to >> learn how I can get you up and productive in Tapestry fast! >> >> (971) 678-5210 >> http://howardlewisship.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de/blog > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
