Gathering of Tweakers

Quicksearch
prutser 1e klasse

We zijn hier hard bezig een JSF applicatie te bouwen welke meerdere talen kan ondersteunen. Op zich niet moeilijk, we proppen gewoon alles in resourcebundle welke we laten vertalen.

Echter, beginnen de resourcebundles een beetje een zooitje te worden. Als je in de resource bundles kijkt is het lang niet altijd duidelijk waar de key voor staat. Er zit geen consistentie in en zo zijn er nog wel wat problemen en onduidelijkheden.

Aangezien ik dit netjes wil gaan oplossen zodat alles eenduidig is, ben ik op zoek naar een structuur / best practice dat een duidelijke mapping geeft tussen property en label.

Op het moment ziet het ongeveer zo uit:
code:
1
2
3
4
5
6
product_tooltip_application=tooltip
product_click_to_edit=Click to edit
OutputLabel=Output
EncryptLabel=Encrypt
application_label_name=Name
DecryptLabel = Decrypt

Zelf had ik het volgende bedacht voor onderdelen die met het object-model te maken hebben:
code:
1
2
3
4
5
6
7
8
# Volledige naam voor bijv. formulier labels
<object>_<attribute> =<value>

# Afgekorte naam voor bijv. column headers
<object>_<attribute>_abbr=<value>

# Omschrijving voor bijv. tooltips
<object>_<attribute>_descr=<value>

Voorbeeld:
employee_phone=Telefoonnummer
employee_phone_abbr=Tel.nr.
employee_phone_descr=Het prive / mobiele nummer waar de werknemen op bereikbaar is.


Specifieke controls, bijv. "Add Employee" button.
code:
1
2
<object>_<control>_<action>=<value>
<object>_<control>_<action>_descr=<value>

Voorbeeld:
employee_button_add=Toevoegen
employee_button_add_descr=Voegt een nieuwe werknemer toe.


Generieke controls, bijv "Back" button:
code:
1
2
<control>_<action>=<value>
<control>_<action>_descr=<value>

Voorbeeld:
button_back=Terug
button_back_descr=Navigeer naar de vorige pagina


Ik vraag me af of dit zo'n beetje alles dekt wat je in een webapplicatie tegen kan komen qua tekst en of ik op de goede weg zit. Heeft er iemand nog iedeeen? Ik wil uiteraard voorkomen dat ik voor verassingen kom te staan of over een paar weken toch weer de heleboel moet omgooien.

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

(inspiratie == 0) -> true

Volgens mij kun je beter keys groeperen dmv punten. Dit wordt vaak ook ondersteund door resource bundle editors waarin je dan een tree structuur krijgt. Verder kun je makkelijk je keys prefixen voor een bepaalde context waarbij je dan in je code niet de hele key hoeft op te geven iedere keer, alleen het gedeelte wat achter de prefix geplakt moet worden.

NetForce1 wijzigde dit bericht 06-06-2008 10:58 (40%)

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

prutser 1e klasse

Om de een of andere reden wil JSF niet werken met punten. De foutmelding die ik dan krijg:
code:
1
2
3
javax.faces.el.PropertyNotFoundException:
value="#{bundle.test.mypoint.menu}" 
Error getting property 'mypoint' from bean of type java.lang.String

En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.


Acties: [view][quote]


Door: Janoz Moderator PRG/SEA/DTE
!litemod
Berichten: 14.688
Reg. datum: 19 oktober 2000

Dat was inderdaad ook een van mijn grootste ergenissen met JSF. De punten worden geinterpreteerd als 'getters'. Ik heb ergens wel eens een oplossing gezien, maar die kan ik nu zo snel even niet terug vinden. Het zal waarschijnlijk iets zijn geweest waarbij een eigen implementatie van de property resolver werd gebruikt.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

(inspiratie == 0) -> true

quote:
Standeman schreef op vrijdag 06 juni 2008 @ 11:18:
En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?
Je hebt bijv. de keys 'dialog.dlgname.action.discardChanges.mnemonic', 'dialog.dlgname.action.discardChanges.caption', 'dialog.dlgname.action.discardChanges.description'. Dit is niet zo fijn om in je code te hebben (net als dat je niet overal fully qualified class names gaat gebruiken). Wat wij nu hebben is een Messages class waaraan je een prefix mee kunt geven, bijv:
Java:
1
messages = new Messages("dialog.dlgname.action.discardChanges")

nu kun je de andere keys simpel benaderen door
Java:
1
2
3
messages.getString("caption");
messages.getString("mnemonic");
messages.getString("description");

Maar wij werken niet met jsf, dus of een soortgelijke aanpak daar ook gaat werken zou ik niet durven zeggen.

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

quote:
Standeman schreef op vrijdag 06 juni 2008 @ 11:18:
Om de een of andere reden wil JSF niet werken met punten. De foutmelding die ik dan krijg:
code:
1
2
3
javax.faces.el.PropertyNotFoundException:
value="#{bundle.test.mypoint.menu}" 
Error getting property 'mypoint' from bean of type java.lang.String

En hoe bedoel je het prefixen voor een bepaalde context. Zou je daar een klein voorbeeldje van kunnen geven?
Je kan het ook op deze manier aanroepen :
code:
1
#{bundle['test.mypoint.menu']}

dat zou gewoon moeten werken.

Blog || Probeer eens een echte db, probeer eens PostgreSQL!
Klik hier voor ultieme ranzigheid! - PSN : Kettrick

prutser 1e klasse

quote:
RoeLz schreef op vrijdag 06 juni 2008 @ 11:46:
[...]


Je kan het ook op deze manier aanroepen :
code:
1
#{bundle['test.mypoint.menu']}

dat zou gewoon moeten werken.
Hey, die kende ik nog niet. Ik ga het gelijk even proberen.

En het werkt \o/ Dat is al een redelijke vooruitgang!

Standeman wijzigde dit bericht 06-06-2008 12:28 (8%)

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

prutser 1e klasse

even een schopje.

Ik kom een andere uitdaging tegen. Ik wil de resource key variabel opbouwen in mijn JSF pagina. Om een even te illustreren:
code:
1
2
tag.9F07=AUC
tag.9F07.descr=Application Usage Control

In mijn object kan ik de tag ophalen door bijv foo.getTag();

Nu wil ik eigenlijk dynamisch de key opbouwen
code:
1
String key = "tag." + foo.getTag() = ".descr".

Ik zit me nu alleen even af te vragen hoe ik dat in mijn bundle['xxx'] ga krijgen

Standeman wijzigde dit bericht 25-06-2008 08:58 (3%)

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

Fallen from grace

bundle[key] zou volgens mij gewoon moeten werken, als de JSP 2.0/2.1 EL regels gelden. Ik weet alleen niet zeker of dat ook voor deferred evaluation geldt.

Confusion wijzigde dit bericht 25-06-2008 09:04 (68%)

Wie trösten wir uns, die Mörder aller Mörder?

prutser 1e klasse

Dat werkt inderdaad prima. Nu nog een manier vinden om de geconcateneerde string er in te prutsen.

hmmm het volgende lijkt niet te werken:
code:
1
2
<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="bundle[tag]"/>

:/

Ook vind ik het eigenlijk niet zo relaxed om JSTL en JSF te mixen..

Standeman wijzigde dit bericht 25-06-2008 10:26 (55%)

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

prutser 1e klasse

Iemand een idee?

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

Fallen from grace

quote:
Standeman schreef op woensdag 25 juni 2008 @ 09:51:
hmmm het volgende lijkt niet te werken:
code:
1
2
<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="bundle[tag]"/>

edit:
Wat hier stond is iets anders dan wat je vraagt.

Wat is de waarde van tag dan nadat die gezet is?

Ah, wacht eens, dat moet iets van
code:
1
<outputText value="#{bundle[tag]}"/>

zijn. Anders wordt 'tag' helemaal niet als variabele geinterpreteerd, maar heeft gewoon de letterlijke stringwaarde 'bundle[tag]'
quote:
Ook vind ik het eigenlijk niet zo relaxed om JSTL en JSF te mixen..
Met alleen JSF kom je niet zo ver; JSF is in feite een uitbreiding van het JSP/EL/JSTL met een lifecycle (en deferred evaluation en de mogelijkheid om een EL expressie als setter te laten fungeren). Voldoende situaties waarin EL/JSTL nuttig waren worden niet door JSF opgelost.

Confusion wijzigde dit bericht 25-06-2008 22:49 (30%)

Wie trösten wir uns, die Mörder aller Mörder?

Design-by-buzzword fanatic
Berichten: 1103
Reg. datum: 11 januari 2004

Over die outputText, je kunt altijd naar Facelets kijken. Dat is een veel krachtigere view definition taal dan JSP. In Facelets kun je bijvoorbeeld gewoon dit doen:
XML:
1
2
3
4
5
<html>
<body>
<h1>#{bundle[tag]}</h1>
</body>
</html>

Geen outputTexts meer nodig. Krijg je veel schonere pagina's van. Ook qua EL heb je voordelen, want met Facelets kun je EL 2.1 (de EL uit JSF 1.2) gebruiken in een JSF 1.1 omgeving.

Fat Pizza's pizza, they are big and they are cheezy

prutser 1e klasse

Ah.. ik zie dat ik een foutje heb gemaakt. Ik was de #{} vergeten op te nemen in mijn post.

Er staat wel degelijk
code:
1
2
<c:set var="tag" value="#{foo.tag}.descr" />
<outputText value="#{bundle[tag]}"/>

Het lijkt er alleen op dat de c:set niet werkt.

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

Fallen from grace

Want wat is de waarde van #{tag} na de set?

Wie trösten wir uns, die Mörder aller Mörder?

prutser 1e klasse

Helemaal niets :/

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

Design-by-buzzword fanatic
Berichten: 1103
Reg. datum: 11 januari 2004

Het is lang geleden dat ik JSF met JSP gebruikt heb, maar probeer eens ${tag}. Wat komt daar uit?

c:set is namelijk geen JSF tag library, maar JSTL. En de lifecycles van die twee matchen niet lekker.

Fat Pizza's pizza, they are big and they are cheezy

prutser 1e klasse

Ik heb eindelijk het probleem gevonden }:|

Ik had xmlns:c="http://java.sun.com/jsp/jstl/core" i.p.v. xmlns:c="http://java.sun.com/jstl/core"

Dan wordt blijkbaar de JSTL gewoon overgeslagen zonder dat je een foutmelding krijgt. c:set werkt nu eindelijk! :)

The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.

Fallen from grace

quote:
JKVA schreef op vrijdag 27 juni 2008 @ 11:25:
c:set is namelijk geen JSF tag library, maar JSTL. En de lifecycles van die twee matchen niet lekker.
De JSTL is aangepast zodat deferred evaluation er ook mee werkt; in principe zou het dus geen problemen op moeten leveren.

Wie trösten wir uns, die Mörder aller Mörder?

Design-by-buzzword fanatic
Berichten: 1103
Reg. datum: 11 januari 2004

quote:
Confusion schreef op vrijdag 27 juni 2008 @ 13:52:
[...]

De JSTL is aangepast zodat deferred evaluation er ook mee werkt; in principe zou het dus geen problemen op moeten leveren.
Klopt, als je de goeie taglib gebruikt. Standeman is niet de eerste die dit overkomt. Voor Facelets is de hele toko herschreven om het te integreren, anders werkte het niet. Het is ook afhankelijk van de JSP/JSF versie die je gebruikt.

Fat Pizza's pizza, they are big and they are cheezy

Moutarde apres le diner

quote:
JKVA schreef op donderdag 26 juni 2008 @ 08:23:
[...]
Geen outputTexts meer nodig. Krijg je veel schonere pagina's van.
Alleen gooi je dan de mogelijkheid weg om je output te escapen, zoals bijvoorbeeld ampersands. Het outputText element kent immers het 'escape' attribuut. Ik vind het om die reden dus altijd zeer wenselijk om tags te gebruiken om text te printen. Je kunt dan immers de intentie van wel of niet escapen kenbaar maken.

Religion has no place in public schools the way facts have no place in organized religion

Design-by-buzzword fanatic
Berichten: 1103
Reg. datum: 11 januari 2004

quote:
mark platvoet schreef op zondag 06 juli 2008 @ 10:20:
[...]
Alleen gooi je dan de mogelijkheid weg om je output te escapen, zoals bijvoorbeeld ampersands. Het outputText element kent immers het 'escape' attribuut. Ik vind het om die reden dus altijd zeer wenselijk om tags te gebruiken om text te printen. Je kunt dan immers de intentie van wel of niet escapen kenbaar maken.
Klopt, maar dat heb je niet altijd nodig. En dan is een extra tag alleen maar extra verbose.

Fat Pizza's pizza, they are big and they are cheezy



© 1998-2008 Tweakers.net BV - Based on React - Hosted by True - Served by Alectrona

© 1998-2008 Tweakers.net BV - Based on React - Hosted by True - Served by Alectrona

[RSS][XML]

Update Tracker

Active Topics
Active Topics
Frontpage Nieuws
Frontpage Nieuws