<div>
<div>
a modelmapper-t még nem ismerem kellő mélységben, de ameddig eljutottam, ez a működés, ami nekem kell, túl alacsonszíntű az ő filozófiájához: a modelmapper különböző pojo-kban gondolkodik, a property-jeit meg azonos konvenciók mentén kezeli. amit írtam, az inkább egy plugin-je lehetne a modelmapper-nek, hisz' a modelmapper funkcionalitásából semmit nem tudtam kihasználni; legfeljebb azt tudnám gazdagítani... nem ismerem még eléggé, de igen szimpatikus tool. :)</div>
<div>
</div>
<div>
a contr-ot majd meglátom. :)</div>
<div>
</div>
<div>
</div>
<div>
g</div>
<div>
</div>
<div>
<br />
"Gábor Garami" <gabor.garami@hron.me> írta:
<blockquote style="border-left:3px solid lightGray;padding-left:3px;">
40 sor, az nem is sok... :-)<br />
<br />
Meg inkabb jobb lenne valahogy a kivetelkezelest belecontributalni a<br />
ModelMapperbe, nem? Vagy azt bonyolult azon a szinten megoldani?<br />
Garami Gábor<br />
E-mail: gabor.garami@hron.me<br />
Tel: +36 20 235 9621<br />
MSN: hrgy@vipmail.hu<br />
Skype: hron84<br />
<br />
<br />
2013/9/20 Cpt <cpt@freemail.hu>:<br />
> Az archívum kedvéért :)<br />
><br />
> Végülis a ModelMapper-ből nem tudtam ezt a működést kierőszakolni, mert nem<br />
> találtam lehetőséget property-k másolásának kivételkezelésére; nekem kellett<br />
> volna a Pojo property-jeit végigiterálnom. Így inkább a<br />
> org.apache.commons.beanutils.BeanUtils csomagot felhasználva írtam egy cirka<br />
> 40 laza soros merge-ölőt.<br />
><br />
> Peresze ezt a megoldást be lehetne csomagolni egy ModelMapper Converter-be,<br />
> ha kéne a ModelMapper robosztussága.<br />
><br />
><br />
> Gábor<br />
><br />
><br />
> Cpt <cpt@freemail.hu> írta:<br />
><br />
> Szerintem, egyre gondolunk, csak más szemszögből nézzük a dolgot. Nem JPA-s<br />
> környezetről van szó (bár, általános a feladat, olyanban is felhasználásra<br />
> kerül, de ez most lényegtelen). Mindössze annyi kötöttség van napjain<br />
> keretrendszeri miatt, hogy ha egy "Root" proxy osztályként kötődik valamihez<br />
> (entity manager-hez vagy bármi máshoz), akkor a kötődés infói ez a tool ne<br />
> rontsa el. Ha a model objektumfában megvan az update-beli entitás (neve<br />
> alapján), akkor azt használja; ha nincs, akkor törölje; ha új, akkor állítsa<br />
> be.<br />
><br />
> Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle<br />
> hozni ezt, csak még nem látom, hogyan...<br />
><br />
><br />
> köszi!<br />
><br />
><br />
> "Gábor Garami" <gabor.garami@hron.me> írta:<br />
><br />
> A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel<br />
> az "update"-ben, de minden "Root"-on kívüli adatot pedig az<br />
> "update"-ből használjon.<br />
><br />
> Szerintem meg kell forditani a gondolatmenetedet. Alapvetoen a model-t<br />
> updateled az update-tel, tehat csak azokat az infokat kell venni az<br />
> update-bol, amik valtoztak. Az update-be pedig meg kell kotni, hogy<br />
> nem kerulhet olyan valtozas, ami a root-ot erintheti.<br />
><br />
><br />
> Ami _szerintem_ megoldas lehet (ha es amennyiben az 'update' pontosan<br />
> ugyanolyan osztalyu, mint a 'model', hogy a sima JPA-s entitymanageres<br />
> merge elott az update-ben felulvagod azokat az elemeket, amiknek nem<br />
> kellene valtozni (igy azok nem is fognak valtozni), utana pedig siman<br />
> csinalsz egy merge-t. Marmint, ha JPA kornyezetu a kerdes (undefined,<br />
> nem irtad).<br />
><br />
> Amennyiben nincs JPA a kozelben, akkor tisztan reflectionnel seem<br />
> ordongosseg megoldani, foleg ha a Java Beanekre vonatkozo megkotesek<br />
> nagy resze be van tartva (gondolok itt a getFoo/setFoo konvenciokra).<br />
><br />
> De esetleg probalhatnad kicsit specifikalni a kornyezetet, lehet, hogy<br />
> van benne olyan megoldas, amit te nem ismersz.<br />
><br />
><br />
><br />
> Garami Gábor<br />
> E-mail: gabor.garami@hron.me<br />
> Tel: +36 20 235 9621<br />
> MSN: hrgy@vipmail.hu<br />
> Skype: hron84<br />
><br />
><br />
> 2013/9/19 Cpt <cpt@freemail.hu>:<br />
>> Sziasztok,<br />
>><br />
>><br />
>> van egy apró feladat, ami gerincében teljesen általános, itt-ott kis<br />
>> specialitással. Találkoztatok már libbel, amit érdemesebb felhasználni,<br />
>> mint<br />
>> leprogramozni?<br />
>><br />
>> Vannak pojo-k, amiknek van 1 közös ős osztályuk, legyen "Root", de<br />
>> tetszőleges mélységű leszármaztatás lehet. Ezen kívül már csak az "alap"<br />
>> osztályokat tartalmazza, mint String, Integer, Date, stb. Ilyen fa<br />
>> struktúrából kettőt kell összemosni, az egyik a "model", a másik az<br />
>> "update"<br />
>> A "Root" osztályokat mindig a "model"-ből vegye, feltéve, ha szerepel az<br />
>> "update"-ben, de minden "Root"-on kívüli adatot pedig az "update"-ből<br />
>> használjon. Az oka, hogy a "Root" osztályokat a "model"-ből kell venni, az<br />
>> az, hogy azok lehetnek proxy osztályok is, amire nincs ráhatásom.<br />
>><br />
>><br />
>> köszi, Gábor<br />
>><br />
>> _______________________________________________<br />
>> Javalist mailing list<br />
>> Javalist@lists.javaforum.hu<br />
>> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
>><br />
> _______________________________________________<br />
> Javalist mailing list<br />
> Javalist@lists.javaforum.hu<br />
> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
><br />
><br />
><br />
><br />
> Szerintem, egyre gondolunk, csak más szemszögből nézzük a dolgot. Nem JPA-s<br />
> környezetről van szó (bár, általános a feladat, olyanban is felhasználásra<br />
> kerül, de ez most lényegtelen). Mindössze annyi kötöttség van napjain<br />
> keretrendszeri miatt, hogy ha egy &quot;Root&quot; proxy osztályként kötődik<br />
> valamihez (entity manager-hez vagy bármi máshoz), akkor a kötődés infói ez a<br />
> tool ne rontsa el. Ha a model objektumfában megvan az update-beli entitás<br />
> (neve alapján), akkor azt használja; ha nincs, akkor törölje; ha új, akkor<br />
> állítsa be.<br />
><br />
> &nbsp;<br />
><br />
><br />
> Nézem a ModelMapper nevű cuccot, elég robosztus, biztos, ki lehet belőle<br />
> hozni ezt, csak még nem látom, hogyan...<br />
><br />
> &nbsp;<br />
><br />
> &nbsp;<br />
><br />
> köszi!<br />
><br />
> &nbsp;<br />
><br />
><br />
> &quot;Gábor Garami&quot; írta:<br />
><br />
> A&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;mindig&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;vegye,&nbsp;feltéve,&nbsp;ha&nbsp;szerepel<br />
> az&nbsp;&quot;update&quot;-ben,&nbsp;de&nbsp;minden&nbsp;&quot;Root&quot;-on&nbsp;kívüli&nbsp;adatot&nbsp;pedig&nbsp;az<br />
> &quot;update&quot;-ből&nbsp;használjon.<br />
><br />
> Szerintem&nbsp;meg&nbsp;kell&nbsp;forditani&nbsp;a&nbsp;gondolatmenetedet.&nbsp;Alapvetoen&nbsp;a&nbsp;model-t<br />
> updateled&nbsp;az&nbsp;update-tel,&nbsp;tehat&nbsp;csak&nbsp;azokat&nbsp;az&nbsp;infokat&nbsp;kell&nbsp;venni&nbsp;az<br />
> update-bol,&nbsp;amik&nbsp;valtoztak.&nbsp;Az&nbsp;update-be&nbsp;pedig&nbsp;meg&nbsp;kell&nbsp;kotni,&nbsp;hogy<br />
> nem&nbsp;kerulhet&nbsp;olyan&nbsp;valtozas,&nbsp;ami&nbsp;a&nbsp;root-ot&nbsp;erintheti.<br />
><br />
><br />
> Ami&nbsp;_szerintem_&nbsp;megoldas&nbsp;lehet&nbsp;(ha&nbsp;es&nbsp;amennyiben&nbsp;az&nbsp;&#39;update&#39;&nbsp;pontosan<br />
> ugyanolyan&nbsp;osztalyu,&nbsp;mint&nbsp;a&nbsp;&#39;model&#39;,&nbsp;hogy&nbsp;a&nbsp;sima&nbsp;JPA-s&nbsp;entitymanageres<br />
> merge&nbsp;elott&nbsp;az&nbsp;update-ben&nbsp;felulvagod&nbsp;azokat&nbsp;az&nbsp;elemeket,&nbsp;amiknek&nbsp;nem<br />
> kellene&nbsp;valtozni&nbsp;(igy&nbsp;azok&nbsp;nem&nbsp;is&nbsp;fognak&nbsp;valtozni),&nbsp;utana&nbsp;pedig&nbsp;siman<br />
> csinalsz&nbsp;egy&nbsp;merge-t.&nbsp;Marmint,&nbsp;ha&nbsp;JPA&nbsp;kornyezetu&nbsp;a&nbsp;kerdes&nbsp;(undefined,<br />
> nem&nbsp;irtad).<br />
><br />
> Amennyiben&nbsp;nincs&nbsp;JPA&nbsp;a&nbsp;kozelben,&nbsp;akkor&nbsp;tisztan&nbsp;reflectionnel&nbsp;seem<br />
> ordongosseg&nbsp;megoldani,&nbsp;foleg&nbsp;ha&nbsp;a&nbsp;Java&nbsp;Beanekre&nbsp;vonatkozo&nbsp;megkotesek<br />
> nagy&nbsp;resze&nbsp;be&nbsp;van&nbsp;tartva&nbsp;(gondolok&nbsp;itt&nbsp;a&nbsp;getFoo/setFoo&nbsp;konvenciokra).<br />
><br />
> De&nbsp;esetleg&nbsp;probalhatnad&nbsp;kicsit&nbsp;specifikalni&nbsp;a&nbsp;kornyezetet,&nbsp;lehet,&nbsp;hogy<br />
> van&nbsp;benne&nbsp;olyan&nbsp;megoldas,&nbsp;amit&nbsp;te&nbsp;nem&nbsp;ismersz.<br />
><br />
><br />
><br />
> Garami&nbsp;Gábor<br />
> E-mail:&nbsp;gabor.garami@hron.me<br />
> Tel:&nbsp;+36&nbsp;20&nbsp;235&nbsp;9621<br />
> MSN:&nbsp;hrgy@vipmail.hu<br />
> Skype:&nbsp;hron84<br />
><br />
><br />
> 2013/9/19&nbsp;Cpt&nbsp;:<br />
>>&nbsp;Sziasztok,<br />
>><br />
>><br />
>>&nbsp;van&nbsp;egy&nbsp;apró&nbsp;feladat,&nbsp;ami&nbsp;gerincében&nbsp;teljesen&nbsp;általános,&nbsp;itt-ott&nbsp;kis<br />
>>&nbsp;specialitással.&nbsp;Találkoztatok&nbsp;már&nbsp;libbel,&nbsp;amit&nbsp;érdemesebb&nbsp;felhasználni,&nbsp;mint<br />
>>&nbsp;leprogramozni?<br />
>><br />
>>&nbsp;Vannak&nbsp;pojo-k,&nbsp;amiknek&nbsp;van&nbsp;1&nbsp;közös&nbsp;ős&nbsp;osztályuk,&nbsp;legyen&nbsp;&quot;Root&quot;,&nbsp;de<br />
>>&nbsp;tetszőleges&nbsp;mélységű&nbsp;leszármaztatás&nbsp;lehet.&nbsp;Ezen&nbsp;kívül&nbsp;már&nbsp;csak&nbsp;az&nbsp;&quot;alap&quot;<br />
>>&nbsp;osztályokat&nbsp;tartalmazza,&nbsp;mint&nbsp;String,&nbsp;Integer,&nbsp;Date,&nbsp;stb.&nbsp;Ilyen&nbsp;fa<br />
>>&nbsp;struktúrából&nbsp;kettőt&nbsp;kell&nbsp;összemosni,&nbsp;az&nbsp;egyik&nbsp;a&nbsp;&quot;model&quot;,&nbsp;a&nbsp;másik&nbsp;az&nbsp;&quot;update&quot;<br />
>>&nbsp;A&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;mindig&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;vegye,&nbsp;feltéve,&nbsp;ha&nbsp;szerepel&nbsp;az<br />
>>&nbsp;&quot;update&quot;-ben,&nbsp;de&nbsp;minden&nbsp;&quot;Root&quot;-on&nbsp;kívüli&nbsp;adatot&nbsp;pedig&nbsp;az&nbsp;&quot;update&quot;-ből<br />
>>&nbsp;használjon.&nbsp;Az&nbsp;oka,&nbsp;hogy&nbsp;a&nbsp;&quot;Root&quot;&nbsp;osztályokat&nbsp;a&nbsp;&quot;model&quot;-ből&nbsp;kell&nbsp;venni,&nbsp;az<br />
>>&nbsp;az,&nbsp;hogy&nbsp;azok&nbsp;lehetnek&nbsp;proxy&nbsp;osztályok&nbsp;is,&nbsp;amire&nbsp;nincs&nbsp;ráhatásom.<br />
>><br />
>><br />
>>&nbsp;köszi,&nbsp;Gábor<br />
>><br />
>>&nbsp;_______________________________________________<br />
>>&nbsp;Javalist&nbsp;mailing&nbsp;list<br />
>>&nbsp;Javalist@lists.javaforum.hu<br />
>>&nbsp;http://lists.javaforum.hu/mailman/listinfo/javalist<br />
>><br />
> _______________________________________________<br />
> Javalist&nbsp;mailing&nbsp;list<br />
> Javalist@lists.javaforum.hu<br />
> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
><br />
><br />
><br />
> &nbsp;<br />
><br />
> _______________________________________________<br />
> Javalist mailing list<br />
> Javalist@lists.javaforum.hu<br />
> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
><br />
><br />
><br />
> _______________________________________________<br />
> Javalist mailing list<br />
> Javalist@lists.javaforum.hu<br />
> http://lists.javaforum.hu/mailman/listinfo/javalist<br />
><br />
_______________________________________________<br />
Javalist mailing list<br />
Javalist@lists.javaforum.hu<br />
http://lists.javaforum.hu/mailman/listinfo/javalist</blockquote>
</div>
</div>
<div>
</div>