Messages vs. String.format()

[Howard Lewis Ship <hl...@gmail.com>]

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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Messages vs. String.format()

[Howard Lewis Ship <hl...@gmail.com>]

On Sat, Mar 13, 2010 at 1:16 AM, Igor Drobiazko
<ig...@gmail.com> 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 <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: Messages vs. String.format()

[Igor Drobiazko <ig...@gmail.com>]

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.

On Fri, Mar 12, 2010 at 6:27 PM, Howard Lewis Ship <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko
http://tapestry5.de/blog