Stałe tekstowe w aplikacji ze Springiem - w jaki sposób je zdefiniować?

Cześć!

Tworzę aktualnie aplikację w Springu. Potrzebuję w aplikacji sporej liczby stałych tekstowych używanych w widoku. Zastanawiam się jaki jest najlepszy sposób zdefiniowana takich Stringów? Plik properties, konfiguracja, plik typu String var = "";?

Wybitny Polityk napisał(a):

Cześć!

Tworzę aktualnie aplikację w Springu. Potrzebuję w aplikacji sporej liczby stałych tekstowych używanych w widoku. Zastanawiam się jaki jest najlepszy sposób zdefiniowana takich Stringów? Plik properties, konfiguracja, plik typu String var = "";?

nie wiem czy najlepszy.. ale ja robilam to za pomoca osobnej klasy w ktorej definiowalam stringi jako pola

public class SecurityProperties {
  public static final String REALM = "MY REALM";

  public static final String HEADER_NAME_REALM = "WWW-Authenticate";
  public static final String HEADER_VALUE_REALM = "Basic realm=";

  public static final String PATH_PATTERN_ROOT = "/";
  public static final String PATH_PATTERN_CHECK = "/check/**";
  public static final String PATH_PATTERN_DASHBOARD = "/dashboard/**";
}

W zwiazku z tym ze wszystkie elementy sa statyczne, nie musisz tworzyc instancji klasy, wywolujesz w ten sposob :

       http.csrf().disable()
                .authorizeRequests()
                .antMatchers(HttpMethod.OPTIONS, "/**").permitAll()
                .antMatchers(SecurityProperties.PATH_PATTERN_ROOT).permitAll()
                .antMatchers("/em/login/").authenticated()
                .antMatchers(SecurityProperties.PATH_PATTERN_CHECK).access(getOrAuthorityExpression(RoleEnum.ADMIN, RoleEnum.WORKER))
                .antMatchers(SecurityProperties.PATH_PATTERN_DASHBOARD).authenticated()
                .and().httpBasic().realmName(SecurityProperties.REALM).authenticationEntryPoint(getBasicAuthEntryPoint())
                .and().sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and().exceptionHandling().accessDeniedHandler(accessDeniedHandler);

To zależy jakie to są stałe, część to mogą być statiki, a częśc np. może być w bazie danych

Najlepsze rozwiązanie według mnie to upchać wszystko w properties (.yaml) i zbindowac wszystko do obiektu który później będziesz mógł sobie wstrzyknąć. Ale faktycznie zależy o jakiś stałych mówimy bo np przechowywanie nazwy pól w properties to troche bez sensu.

Pytanie - co ty w tych Stringach trzymasz?

1. Jeśli jakieś teksty, które są dla użytkownika to plik properties, przy zmianie języka łatwiej podmienić.
2. Jeśli jakieś stałe związane ze stricte aplikacją (ścieżki do zasobów) to można korzystać z interfejsów, ale i z properties też.
3. Jeśli w innych aplikacjach takie rzeczy też występują to pewnie gdzieś tam leży biblioteka - wtedy najłatwiej korzystać z tego.

I18n --> spring

Do tego można mieć coś takiego:

public class StringProvider {

    private static final ResourceBundle resourceBundle = init();

    private StringProvider() {
    }

    public static String getString(String key) {
        try {
            return resourceBundle.getString(key);
        } catch (MissingResourceException e) {
            return key;
        }
    }

    private static ResourceBundle init() {
        return ResourceBundle.getBundle("locale/messages", new Locale("pl", "PL"));
    }

}

A plik z wiadomościami leży w /src/main/resources/local i nazywa się messages_pl.properties
i masz tam wpisy typu
klucz1=Moja wiadomość

Potem StringProvider.get("klucz1") i masz to co chcesz :)

@artur52: Tutaj też zależy od case'a. Choć jestem prawie pewien że messages da sie jednak pobrać w zdecydowanie ładniejszy sposób ;)

Edit: Zgadza sie -> Internacjonalizacja

Do innych przypadków:

@AllArgsConstructor
@Data
@ConfigurationProperties
public class Settings {
     private String contrain1;
     private int contrain2;
    ....
}

No i koniec. Dziękuje dobranoc :)

Dziękuję wszystkim za odpowiedzi. Jeśli chodzi o to do czego te Stringi są potrzebne - są to teksty wyświetlane użytkownikowi na różne sposoby, czy to w plikach wyjściowych czy w widoku.

Z dotychczasowych wypowiedzi wnoszę, że najlepszym rozwiązaniem będzie właśnie skorzystanie z internacjonalizacji, dziękuję :)