Visualizzazione dei risultati da 1 a 5 su 5
  1. #1
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615

    [Java][Best practice] .xml vs .properties

    Cari utenti,
    le pagine web della mia dynamic web app contengono un menu con diverse proprietà (nomi dei pulsanti, link che questi aprono, colori associati, codice del tipo di utente che può vederli eccetera). Ho messo tutte le informazioni di questo menù in un apposito file .properties, con una lista di stringhe che definiscono informazioni associate a ciascuna voce, per non "sporcare" il file web.xml che dovrebbe invece essere destinato ad altro, e per non creare un nuovo file .xml in quanto credo che un file di proprietà sia formalmente più idoneo allo scopo.

    E' stata corretta la mia scelta?

    Grazie!

  2. #2

    Re: [Java][Best practice] .xml vs .properties

    Originariamente inviato da Shadow976
    Cari utenti,
    le pagine web della mia dynamic web app contengono un menu con diverse proprietà (nomi dei pulsanti, link che questi aprono, colori associati, codice del tipo di utente che può vederli eccetera). Ho messo tutte le informazioni di questo menù in un apposito file .properties, con una lista di stringhe che definiscono informazioni associate a ciascuna voce, per non "sporcare" il file web.xml che dovrebbe invece essere destinato ad altro, e per non creare un nuovo file .xml in quanto credo che un file di proprietà sia formalmente più idoneo allo scopo.

    E' stata corretta la mia scelta?

    Grazie!
    Direi di si . Per il web.xml non è solo questione di "non sporcarlo", esternalizzare la configurazione in uno o più file di properties (o anche xml se i la configurazione è molto strutturata e vuoi ottenere maggiore leggibilità) consente facilmente di profilare l'applicativo per diversi ambienti di deploy: sviluppo, pre-produzione, produzione....
    Il centro dell'attenzione non è sempre un buon posto in cui trovarsi

    Mai discutere con uno stupido, la gente potrebbe non capire la differenza. (O. W.)

  3. #3
    Utente di HTML.it
    Registrato dal
    May 2005
    Messaggi
    615
    Grazie infinite!

  4. #4
    a me non sembra una buona soluzione utilizzare un file properties per un menu
    la trovo "forzata"....

    un xml (o json, in questi ultimi tempi va un casino ) puo rappresentare una soluzione più completa in quanto, come nel tuo caso può facilmente descrivere le proprietà del menu.

    come hai gia espresso tu, ogni singola voce del menu avra delle sue proprietà, immagino : indirizzo di destinazione, nome della voce di menu, ecc ecc

    come lo rappresenti in un file properties che una becera coppia nome-valore?

  5. #5
    Originariamente inviato da GringoMrk
    a me non sembra una buona soluzione utilizzare un file properties per un menu
    la trovo "forzata"....

    un xml (o json, in questi ultimi tempi va un casino ) puo rappresentare una soluzione più completa in quanto, come nel tuo caso può facilmente descrivere le proprietà del menu.

    come hai gia espresso tu, ogni singola voce del menu avra delle sue proprietà, immagino : indirizzo di destinazione, nome della voce di menu, ecc ecc

    come lo rappresenti in un file properties che una becera coppia nome-valore?
    Un xml è indubbiamente più adatto per rappresentare dati molto strutturati, tuttavia se proprio si deve anche con un file di props lo si può fare, è sufficiente utilizzare una stretta convenzione nel nominare le chiavi e scrivere un po di codice per salvarle e leggerle dinamicamente:

    codice:
    ...........
    menu.1.color=#ffff
    menu.1.src=/files/blabla
    
    menu.2.color=#b4b4b4b
    
    .......
    Il centro dell'attenzione non è sempre un buon posto in cui trovarsi

    Mai discutere con uno stupido, la gente potrebbe non capire la differenza. (O. W.)

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.