Where should I put generic string label

Where should I put generic string label

  

There are many repeated string labels. For example on table record empty message "No item to show..."

Another one like for feedback message. I want to have a generic confirmation message like "Your data has successfully saved".

But I'd like to avoid repeat typing those labels over and over again and also possibility in future when it changes developer only need to change it once for all.

So where to store this labels resources? While also not forgetting multi language support factor. I was thinking to store it in static entity but it will cost some read IO since it is a table. I prefer it to be static variable. Should it be on session? Site resources? Or what is the best practice?

Solution

Hi Eric,

You can create a common Method for all message. Just pass one input parameter as a code and get Message as a output. It could be one way. 


-Hitesh-

Solution

I don't recommend doing this.

Good practice says that, the messages should be specific and meaningful, not generic. 

This means that every message should be local to the action executed, being a success or fail message.

Cheers,

Eduardo Jauch

I fully agree with Eduardo. You should e.g. instead of "No items to show..." have "No articles to show...", "No customer to show..." etc. And instead of "Your data is succesfully saved", "The product is (...)", "The user data is (...)" etc.

That said, afaik Static Entities are cached, so a read shouldn't be that expensive.

You right but in this case we want to minimize the use of static entity and minimize maintenance of having "different" labels since different developers might have different saying in labels. Plus having 1 generic message will reduce translation in multi-language support I guess.

Hitesh Maran wrote:

Hi Eric,

You can create a common Method for all message. Just pass one input parameter as a code and get Message as a output. It could be one way. 


-Hitesh-

Hmm interesting could be a solution


Hi Eric,

While the way to go would be the one provided by Hitesh, You will not be decreasing maintenance cost.
You will have to keep track of what code to send to retrieve the message, and this alone will be bad enough to developers.

Or you will have to keep a Static Entity to make maintenance easier, and will defeat the purpose of not using Static Entities (that make life easier).

The only advange would be in the multi language effort.
But the cost is usability. 

You are making the adoption of your software harder, instead of making it easier.

In the end, you are providing a much worse product to the client, trying to save a "little" in development effort, that in the end will be replaced by other costs...

I still don't recommend.

Cheers,
Eduardo Jauch

Hmm I see ok thanks for your suggestion. We will consider it thoroughly before actually implement it.