The Java classes ResourceBundle and MessageFormat provide a nice toolset for resolving localized messages inside Java applications. This post provides a small example on how you can move simple message related conditions from your Java code into message files using ChoiceFormat. If you already know ChoiceFormat I do not think you will learn anything new in this post. However, in my experience many developers do not know about this nice little feature.Let's assume we have an application in which users can comment some kinds of content. Somewhere in the application we want to display a simple message that shows how often a certain piece of content has been commented. We want to show the following messages based on the number of comments: Number of comments Message 0 This element contains no comments 1 This element contains one comment 2+ This element contains comments To implement this
Egy érdekes példa a properties fájlokról, s arról, hogy miképp tudunk különféle logikát beletenni (például darabszám paraméterfüggő kiírását), hogy kisebb legyen a forrásunk kódbázisa, ezzel átláthatóbb kódot tudunk készíteni.
A cégnél parázsvita alakult ki a cikk kapcsán. Hogy valóban jó dolog-e..
Nekem tetszik a megoldás, feleslegesnek tűnő kódsorokat tudunk megspórolni, ami java esetén szerintem nem hátrány, hiszen alapvetően elég pazarló ilyen tekintetben.
Egyik munkatárs azzal érvelt ellene, hogy mi van, ha az ügyfél is szerkesztheti a properties fájlokat, hogy kedve szerint átírhassa a szövegeket. Ekkor vagy egy kisebb tanfolyamot kell tartani a számára, hogy ezeket is tudja értelmezni és szerkeszteni (és hogy ne produkáljon számunka bug reportokat ), vagy buktuk azt, hogy az ügyfél nyelvesíti az alkalmazást.
Másik munkatárs szerint ez olyan, mint mikor C-ben egy sorba leírjuk azt, amit egy normális programozó 15-ben. Bukjuk vele a tiszta kódot. Jelen esetben a tiszta properties fájlt, illetve elrejtünk vele logikákat, amiket később esetleg egy kolega nehezen talál meg.
Végül nagyjából megegyeztünk abban, hogy minden eszköz használhatóságát és hozzáadott értékét abban a környezetben lehet csak megítélni, ahol használni kívánjuk.
Ráadásként arra jöttünk rá, hogy a JSF is fel kell hogy tudja oldani ezeket a Stringeket, hiszen a MessageFormat saját magán belül dönti el, hogy kell-e használni a ChoiceFormat-ot, vagy sem.
3 Comments
Auth Gábor
Futó Tamás
A cégnél parázsvita alakult ki a cikk kapcsán.
Hogy valóban jó dolog-e..
Nekem tetszik a megoldás, feleslegesnek tűnő kódsorokat tudunk megspórolni, ami java esetén szerintem nem hátrány, hiszen alapvetően elég pazarló ilyen tekintetben.
Egyik munkatárs azzal érvelt ellene, hogy mi van, ha az ügyfél is szerkesztheti a properties fájlokat, hogy kedve szerint átírhassa a szövegeket. Ekkor vagy egy kisebb tanfolyamot kell tartani a számára, hogy ezeket is tudja értelmezni és szerkeszteni (és hogy ne produkáljon számunka bug reportokat
), vagy buktuk azt, hogy az ügyfél nyelvesíti az alkalmazást.
Másik munkatárs szerint ez olyan, mint mikor C-ben egy sorba leírjuk azt, amit egy normális programozó 15-ben. Bukjuk vele a tiszta kódot. Jelen esetben a tiszta properties fájlt, illetve elrejtünk vele logikákat, amiket később esetleg egy kolega nehezen talál meg.

Végül nagyjából megegyeztünk abban, hogy minden eszköz használhatóságát és hozzáadott értékét abban a környezetben lehet csak megítélni, ahol használni kívánjuk.
Ráadásként arra jöttünk rá, hogy a JSF is fel kell hogy tudja oldani ezeket a Stringeket, hiszen a MessageFormat saját magán belül dönti el, hogy kell-e használni a ChoiceFormat-ot, vagy sem.
Auth Gábor
Örülök, hogy elgondolkodtató cikket találtam...