Registrazione globale dei formati di campo in Wicket

Ho studiato attentamente Jonik's entry sulla personalizzazione della formattazione BigDecimal in Wicket. Grazie per questo eccellente pezzo di codice. Purtroppo non riesco a farlo funzionare per il mio caso d'uso.Registrazione globale dei formati di campo in Wicket

Vorrei iscrivermi formattazione data a livello globale e sto usando il seguente codice nella sottoclasse di applicazione:

@Override 
protected IConverterLocator newConverterLocator() { 
    ConverterLocator converterLocator = new ConverterLocator(); 
    converterLocator.set(Date.class, new DateConverter() { 

     @Override 
     public DateFormat getDateFormat(Locale ignore) { 
      return new SimpleDateFormat("dd.MM.yyyy HH:mm:ss"); 
     } 

    }); 
    return converterLocator; 
}

Poi quando si utilizza campi data nelle pagine web il codice è il seguente:

form.add(new TextField<Date>("dateField"));

Durante il rendering, i campi della data mostrano il formato standard java.text.DateFormat.SHORT (02.11.11 11:59) proveniente dalla classe org.apache.wicket.util.convert.converter.DateConverter anziché dal mio SimpleDateFormat personalizzato (02.11.2011 11:59:42).

Ho verificato che java.util.Date viene utilizzato in tutto. La versione di Wicket è 1.4.12.

Qualche idea?

fonte

2011-11-09 Paul Buller

Questo sta funzionando bene in un avvio rapido 1.4.12, utilizzando il nuovo TextField ("dataField", nuovo modello (nuova data())). Qual è il modello del TextField? Se il Form ha un CompoundPropertyModel, quale classe è la proprietà dateField si risolve? –

Grazie Xavi. Il form è un 'CompoundPropertyModel' che si riferisce a un'entità di persistenza il cui' dateField' è java.util.Date. Dato che stiamo usando entità di persistenza, i campi alla fine dei getter/setter chainings sono tipi di dati Java non elaborati, non implementazioni di IModel. È questo il problema? –

Sei sicuro che il tuo 'newConverterLocator()' è in uso? Hai eseguito il debug di 'Component.getConverter (Class)' per vedere cosa sta succedendo? Puoi farlo facilmente inserendo un breakpoint in un override in questo particolare componente. –

Penso che il tuo dateField abbia tipo java.util.Date, ma l'oggetto reale (caricato dal database?) È ad es. java.sql.Timestamp o un altro bambino di java.util.Date. Ecco perché ConverterLocator sceglie un altro convertitore invece del tuo. Il codice sorgente del ConverterLocator ha la seguente:

set(Date.class, new DateConverter()); 
set(Calendar.class, new CalendarConverter()); 
set(java.sql.Date.class, new SqlDateConverter()); 
set(java.sql.Time.class, new SqlTimeConverter()); 
set(java.sql.Timestamp.class, new SqlTimestampConverter());

Quindi, è necessario conoscere l'esatto tipo run-time del dateField e sovrascrivere convertitore per esso.

fonte

2011-11-09 13:14:47 kan

Inoltre, evitare di utilizzare 'java.util.Date' nel codice. Utilizzare tipi più specifici - 'java.sql.Date' per una data (ad esempio una data di nascita), java.sql.Time per un momento (ad esempio un orario di arrivo del treno) e java.sql.Timestamp per il momento esatto di tempo (ad esempio un orario di incontro programmato). – kan

+1 per l'utilizzo dell'origine, anche questa è probabilmente la ragione per cui sta ancora usando 'DateFormat.SHORT', sembrano tutti predefiniti. –

@ XaviLópez Ti dico che ha un convertitore sovrascritto solo per 'java.util.Date', ma il suo vero tipo è qualcosa di diverso, molto probabilmente' java.sql.Timestamp', quindi wicket usa quello predefinito. – kan

Registrazione globale dei formati di campo in Wicket

risposta

Problemi correlati