Lokalizacja JSF 2 (managed bean)

Łatwiej jest używać np. modułu komunikatów MyFaces CODI !

Możesz to zrobić tylko z JSF.

Zacznij od zdefiniowania zarządzanej nieruchomości na Twoim zapleczu. W konfiguracji JSF można ustawić wartość właściwości managed na wyrażenie EL, które odwołuje się do pakietu zasobów.

Zrobiłem coś takiego jak poniżej używając Tomcat 6. Jedynym zastrzeżeniem jest to, że nie możesz uzyskać dostępu do tej wartości z konstruktora backing bean, ponieważ JSF jeszcze go nie zainicjalizuje. Użyj @PostConstruct w metodzie inicjalizacji, jeśli potrzebna jest wartość na początku cyklu życia fasoli.

<managed-bean>
  ...
  <managed-property>
    <property-name>messages</property-name>
    <property-class>java.util.ResourceBundle</property-class>
    <value>#{msgs}</value>
  </managed-property>
  ...
</managed-bean>

<application>
  ...
  <resource-bundle>
    <base-name>com.example.messages.messages</base-name>
    <var>msgs</var>
  </resource-bundle>
  ...
</application>

Ma to tę zaletę, że Twoje metody tworzenia kopii zapasowych są mniej zależne od technologii prezentacji, więc powinno być łatwiejsze do przetestowania. Oddziela również Kod od szczegółów, takich jak nazwa nadana pakietowi.

Niektóre testy przy użyciu Mojarra 2.0.4-b09 wykazują małą niespójność, gdy użytkownik zmienia ustawienia regionalne w połowie sesji. Wyrażenia na stronie el używają nowych locale, ale fasola zaplecza nie otrzymuje nowego odniesienia do ResourceBundle. Na aby była spójna można użyć wartości właściwości bean w wyrażeniach EL, takich jak użycie #{backingBean.messages.greeting} zamiast #{msgs.greeting}. Następnie page EL i backing bean zawsze używali ustawień regionalnych, które były aktywne w momencie rozpoczęcia sesji. Jeśli użytkownicy mieli , aby przełączyć lokalizacje w połowie sesji i uzyskać nowe wiadomości, możesz spróbować zrobić request-scoped bean i nadać mu odwołania do zarówno sesji bean, jak i pakietu zasobów.

Oto przykład jak to zrobić: http://www.laliluna.de/articles/javaserver-faces-message-resource-bundle-tutorial.html

Chcesz rzucić okiem na ResourceBundle.getBundle() część.

Pozdrawiam, Lars

To stare pytanie, ale dodaję inny sposób. Szukałam czegoś innego i natknęłam się na to. Metody tutaj wszystko wydawało się zawiłe dla czegoś, co nie wydaje mi się tak trudne. Bawię się brokatem, bo jest ładny.

Podany PLIK:

/com/full/package/path/to/messages/errormessages.properties

Wewnątrz pliku:

SOME_ERROR_STRING=Your App Just Cratered

Tworzę metodę" getBundle ()", ponieważ lubię przechwytywać runtime i dodawać sensowną wiadomość, więc zrozumiem, gdzie nadchodzi od. Nie jest trudne i może pomóc, jeśli z jakiegoś powodu masz kaprys, aby grać z plikami właściwości i nie aktualizować wszystkiego poprawnie. Czasami robię to prywatnie, ponieważ czasami jest to metoda pomocnicza w ramach klasy (dla mnie). Dzięki temu problem try catch nie jest widoczny w znaczącym kodzie.

Użycie pełnej ścieżki do pliku pozwala umieścić go w innym miejscu niż domyślna lokalizacja / katalog, jeśli masz inne pomysły na organizację.

public/private ResourceBundle getMessageResourceBundle(){
    String messageBundle = "com.full.package.path.to.messages.errormessages";
    ResourceBundle bundle = null;
    try{
        bundle = ResourceBundle.getBundle(messageBundle);
    }catch(MissingResourceException ex){
        Logger.getLogger(this.getClass().getName()).log(Level.SEVERE,
                    "Unable to find message bundle in XYZ Class", ex);
        throw ex;
    }

}

public void doSomethingWithBundle(){

    ResourceBundle bundle = getMessageResourceBundle();
    String someString = bundle.getString("SOME_ERROR_STRING");
    ...
}