jackson mapper
On 1/18/18, Angelo Marlo angelo.marlo....@gmail.com
[it-torino-java-jug] <it-torino-java-jug@yahoogroups.com> wrote:
> Ciao a tutti,
> non ho letto tutti i posts quindi potrei ripetere il tema.
> Nel riversamento da un bean a un altro, l'ho fatto con metodi automatici
> alla dozer, che però mi è parso rigido, e poi a mano.
> Quando l'ho realizzato a mano ho trovato sempre un problema ricorrente
> fastidioso, quello ad esempio del tipo
>
> obj1.setCampo(obj2.getCampo1().getCampo2()
> ..getCampo3.getCampo4()....)
> e doverci fare il controllo dei null. allora, con java8 avevo pensato di
> trasformare tutto in un supplier con l'ultimo get così ::getn
> e infilarlo in un metodo di utility tipo checkNull ma fatto in scala dove
> il parametro è del tipo
>
> checkNull(supplier : => Supplier[t]) {
> T result = null;
> try {
> result = supplier.get();
> } catch (NullPointerException e) {
>
> result = null;
> }
> result;
> }
>
> Ora personatemi la sintassi in Scala perchè è da un po' che non lo uso
> però, essendo il parametro supplier con => valutato solo al momento in cui
> viene usato, potrebbe funzionare? Non ho avuto il tempo di realizzarlo
> praticamente, benchè semplice.
> In java il parametro lo calcolerebbe, benchè sia cmq una funzione, prima di
> entrare nel metodo, e lasciare non calcolato l'ultimo pezzo che crea il
> supplier, cioè il ::getn.
>
> Che ne pensate. Non parlatemi degli Optional in java perchè mi pare troppo
> verbosa come soluzione. Meglio allora gli if semplici a blocchi nella lista
> si set e get del metodo di riversamento.
>
>
> Ciao, Angelo
>
> Il giorno 18 gennaio 2018 21:16, Roberto Franchini ro.franch...@gmail.com
> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com> ha scritto:
>
>>
>>
>>
>>
>> 2018-01-18 19:44 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com
>> [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>:
>>
>>>
>>>
>>> Ciao Federico,
>>>
>>> Riguardo l'approccio con la mappa, mi sembra un modo di aggirare il
>>>> problema di stare usando Java. Quest'approccio mi fa tornare in mente
>>>> un
>>>> articolo di Martin Fowler che diceva che comunque tu hai sempre uno
>>>> schema
>>>> dei dati, che sia implicito ed esplicito (forse era qui:
>>>> https://martinfowler.com/articles/schemaless). Questo perche'
>>>> l'utilizzatore andra' a leggersi certi campi, avra' certe aspettative.
>>>> Per
>>>> cui mi conforta avere lo schema esplicito, sotto forma di classe.
>>>> D'altra
>>>> parte se ti scrivi gli opportuni test lo schema lo vai invece a
>>>> "cristallizzare" nei test. L'approccio a classi, oltre all'aiuto del
>>>> compilatore mi darebbe la possibilita' di usare la reflection dove
>>>> serve.
>>>>
>>>
>>> Grazie, molto bello l'articolo.
>>>
>>> Però sostanzialmente conferma la mia reticenza ad usare le mappe: nel
>>> nostro caso il problema non è tanto il fatto di non conoscere a priori
>>> la
>>> struttura dati e non è il fatto che la struttura non sia uniforme (due
>>> dei
>>> tre trigger che utilizza per scegliere che tipo di schema utilizzare).
>>> Il
>>> problema è il numero di trasformazioni inutili che facciamo in rapporto
>>> al
>>> numero di quelle realmente utili.
>>>
>>>
>> Si', le orogini della nostra scelta passata si basavano proprio sul fatto
>> che non sapevamo mai da dove ed in che formato sarebbero arrivati i
>> prossimi dati e dove e come li avremmo esportati/visualizzati.
>>
>>
>> [cut]
>>
>>
>>> Mi togliete una curiosità dovuta alla mia ignoranza: perché proprio
>>> Kotlin? Mi sarei aspettata di vedere citati diversi linguaggi la cui
>>> sintassi facilita lo sviluppo, invece c'è il coro unanime pro-Kotlin.
>>> Come
>>> mai?
>>>
>>>
>> Ci sono svariati motivi:
>> - e' tipato e compilato
>> - e' veramente interoperabile con Java: da kotlin usi java e da java usi
>> kotlin
>> - i progetti multilinguaggio FUNZIONANO.
>> - e' un linguaggio moderno, pulito, senza tutto il boilerplate di java
>> - e' abbastanza funzionale
>> - e' ad oggetti
>> - la curva di apprendimento e' piatta
>> - l'ide ti aiuta un sacco (copia codice java in file kotlin, te lo
>> converte :) )
>>
>>
>> sto andando per gradi, ora ho il primo codice in produzione in Kotlin
>> dentro ad un progetto Java ed una piccola libreria full kotlin.
>> full kotlin vuol dire che anche il file di build di gradle e' scritto in
>> kotlin.
>> Per il progetto misto, ho aggiunto 4 righe in gradle, ha funzionato
>> tutto..
>> Quando avro' un intero progetto scritto con un solo linguaggio,dalla
>> build
>> al frontend, e quel linguaggio non sara' JS, daro' una festa.
>> FRANK
>>
>>
>> --
>> Roberto Franchini
>> "The impossible is inevitable"
>> https://github.com/robfrank/
>> https://twitter.com/robfrankie
>> https://www.linkedin.com/in/robfrank
>>
>>
>>
>
--
https://mybizcard.co/ivan.rovano.81189
