- Xiaomi 15 - kicsi telefon nagy energiával
- Szerkesztett és makrofotók mobillal
- Xiaomi Mi 11 Ultra - Circus Maximus
- Samsung Galaxy A72 - kicsit király
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Honor 200 Pro - mobilportré
- Huawei Watch Fit 3 - zöldalma
- Magisk
- Ilyen lesz a Fairphone 6
- Motorola Edge 40 - jó bőr
Új hozzászólás Aktív témák
-
floatr
veterán
válasz
MrSealRD
#4939
üzenetére
Megpróbálom összeszedni majd a dolgokat hozzá pár napon belül
A spring MVC már nagyon nem az a fajta állat, amikor a java kódnak bármi köze is lenne a html-hez. A legegyszerűbb felállás az -- ahogy struts esetében is van -- hogy egy adott URL-en van egy osztályod, ami reagál valami interakcióra, vagy listákat készít (bármi), meg egy JSP, ami a művelet eredményei megjeleníti. Az osztály az adatokat request-ben tárolja, az oldal meg onnét veszi ki, esetleg használhatsz hozzá taglib-et, de a magam részéről már régóta kerülök minden ilyent, max ha nagyon ostomba browserre kell optimalizálni.
pl ki akarod listázni a felhasználókat:
http://szerverem/users.html --> a spring mappeli a requestet a megadott osztály egyik metódusára, az kipréseli a listát adatbázisból, requestbe pakolja, majd a megmondja, hogy melyik JSP jeleníti meg. A spring megkeresi a JSP-t, onnantól meg rajtad múlik, hogy mennyire használsz java kódot. Ehhez képest a REST WS csak egy kicsit egyszerűbb: a metódus objektumot ad vissza, amiből beállítástól függően a spring pl. Jackson-nal JSON-t tol át, aztán egy kliens összerak belőle egy listát.
Szépen el van választva egymástól minden. Én is utálom, amikor kavarodnak a dolgok. -
floatr
veterán
válasz
MrSealRD
#4923
üzenetére
Egy ideje ezen az architektúrán fejlesztek, úgyhogy csak ajánlani tudom. Ha a cél egy olyan vékony kliens, ami mobilon is életképes, akkor érdemes még fontolgatni az MVC-t, bár az újabb telefonok már az ExtJS/Sencha Touch elemekkel is jól kijönnek. Spring MVC-t nem feltétlenül kell használni egy ilyen projektben, mert sokkal több dolog van benne, mint ami kellhet. Adatkapcsolati eszközként én DWR-t használom.
JQuery: gyakorlatilag ipari standard bár verziófüggőségi problémákkal én rengeteget szoptam. A korábban frontenddel foglalkozó fejlesztők szeretik, mert közelebb áll az ő gondolkodásmódjukhoz, de ha komplexebb dolgot kell benne megvalósítani, akkor a pluginekkel elég nagy problémákat vesz a nyakába az ember, mivel elég sovány a támogatásuk. Ha az ember nem expert, akkor csak a pluginek közti turkálás lesz belőle.
ExtJS: én ezt használom régóta, és a legtöbbször ezt is javaslom. Jó a supportja, és elég sokrétű felhasználási lehetőségei vannak. Egyrészt a magja közelebb áll a Java-s fejlesztőkhöz, és kellően testreszabható ahhoz h saját komponenseket használj tetszőleges felületi elemekhez. Másrészt van egy elég komoly adatkezelési mechanizmusa, aminek szvsz még a dojo sem ér a nyomába. Aztán ott van a komponenskészlete, ami desktop alkalmazások építőelemeire hajaz, és ráadásul még az ie6 is támogatott.
DWR: ha nem ismered, akkor nosza rajta. Írni is akartam egy kisebb cikket ezzel kapcsolatban, mert sokaknak teljesen ufó a dolog. A lényege annyi, hogy egy webservice-szerű szolgáltatási réteget a szerveren bekonfigurálva generál egy javascript csomagot, amiben megtalálod a szolgáltatásaid metódusait, és az adathordozó osztályokat. Magyarán JS-ből közvetlenül eléred a Java szolgáltatásaidat úgy, hogy még a bean-jeidet is létre tudod hozni a kliensnél. ExtJS-hez pár bővítmény kell, hogy az adatkapcsolat kezelhető legyen (én írtam ilyent
)Spring MVC: a DWR nem egy szabványos rendszer, ezért gyakran előfordul, hogy a spring RESTful webservice eszköztárára van szükség. Mondjuk ez sem teljesen szabványos, mint implementáció, de ezt legalább tudod használni bármilyen servlet konténerrel, nem kell hozzá vaskos JBoss. Jackson2-vel használva egy JS library számára az egyik legkezesebb eszköz. Tudok hozzá adni olyan komponenst ExtJS-hez, amivel majdnem DWR-szerű hívások szintjére lehet felhozni a kezelhetőségét.
Spring konténer: én enélkül el sem indulnék egy projektben
elsősorban XML-alapú konfigurációval.Hibernate: próbáltam szabadulni tőle, de mindig ide jutottam vissza. Amikor hierarchikus adatmodelled van, nem mondom h megkerülhetetlen, de erősen ajánlott. Főként a komplexebb lekérdezéseknél jól jön a HQL és a natív SQL-binding. Spring-gel együtt használva érdemes a Spring Data/JPA oldaláról támadni, mert az mégiscsak modernebb, mint a HibernateTemplate. Kísérleteztem még QueryDSL-el is, de azt csak egyszerűbb lekérdezésekig érdemes használni -- mondjuk azokra mindenképpen érdemes.
-
-
-
Karma
félisten
-
-
pakriksz
őstag
-
#4248
WonderCSabo
félisten
MrSealRD
#4245
WonderCSabo
félisten
válasz
MrSealRD
#4245
üzenetére
Tévedsz, Javában a string literálok nem úgy műkődnek, mint az egyéb sima objektumok. Ezek egy String poolba kerülnek. Amikor létrehozol egy új string literált, akkor a JVM megnézi, hogy benne van-e már az a string a poolban, és ha igen, akkor nem hoz létre új objektumot, hanem egyszerűen referál a már meglévőre. A garbage collector ezeket a stringeket nem is fogja bántani csak úgy, különben elveszik az újrafelhasználás lehetősége.
A StringBuildert pedig nem kell feltétlenül használni, mert egyrészt sokkal természetesebb a plusz operátor, másrészt úgyis StringBuilderre fordul a + operátor...
-
válasz
MrSealRD
#4245
üzenetére
sb.replace(0,sb.length,"x")
Ekkor is létrehozol egy "x" (vagy akármi más) tartalmú String objektumot. Tény, hogy utána a régi literált nem kell GC-zni, mert egyszerűen felülcsapja az új literállal a karaktertömbjét, de ha picit utánaolvasol annak, hogy mi az a PermGen, akkor rájössz, hogy alapesetben a régi Stringet sem fogja megenni a GC. Annyit értél el az egésszel, hogy rondább lett a kód.
-
modder
aktív tag
válasz
MrSealRD
#4239
üzenetére
Esküszöm, nem értem, mit akarsz mondani Superhun válaszára.
De pár tény:
1) A JVM k*rva okos és tele van optimalizációval. Memória allokációnak alig van költsége, persze sok kis objektum lassíthatja a GC-t. Megoldás: arra az objektumra ne veszítsük el a referenciát, amit újra fogunk használni. Ennek megkönnyítésére szoktak memory poolokat implementálni Javában úgy, ahogy C++-ban is. De ezeket elég speckó esetekben szokták használni, amikor a sebesség van mindenek felett.
2) literálokra referencia mindig ugyanarra a memóriaterületre mutat. for() { String s = "nyorr"; } nem fog új objektumot létrehozni minden egyes iterációban
3) Olyan mikro-optimalizációról beszélünk, aminél egy adatbázis lekérdezés nagyságrendekkel lassabb: semmi értelme gondolkodni rajtaCiklusban String összefűzést StringBuilderrel, mert azt a compiler tudtommal nem ismeri fel, ellenben a "egy" + "ketto" + $valami.toString; kóddal, amit StringBuilderre cserél (vagy StringBuffer, most hirtelen nem emlékszem, melyik a thread-safe)
Nem látom értelmét String helyett StringBufferben tárolni a stringet.
Szerk.:
Közben rájöttem, mit akartál mondani, de elég veszélyes. Ha Stringbuilderben tárolod a stringeket, akkor a StringBuilder mutable, és olyan helyen is megváltoztathatod a String értékét, ahol nem akarod. pl.:StringBuilder strTime = getTimeInString();
page1.setLastVisited(strTime);majd később:
StringBuilder strTime = getTimeInString();
page2.setLastVisited(strTime);no shit, lastVisited szintén frissült page1-re, mert ugyanaz az objektum. Nem hiába találták ki, hogy a String immutable.
-
TBG
senior tag
válasz
MrSealRD
#4239
üzenetére
Ez csak abban az esetben jelenthet gondot, ha több tízezres/százezres nagyságrendben "kallódnak" az objektumok. Ergó, a felhasználástól is függ, hogy az ember hogyan hegyezi ki a kódot. Illetve érdemes-e nagyon kihegyzeni. Mindenesetre ökölszabály, hogy ha tökmind1, akkor is a szebb, takarékosabb megoldást használjuk.
-
válasz
MrSealRD
#4234
üzenetére
A példaként hozott esetben a StringBuilder használata teljesen indokolatlan, hiszen nem karakterlánc hozzáfűzés/zsugorítás történt, hanem egy teljes csere. StringBuilder használata akkor javasolt és szép, ha ciklusban használod a String += operátorát, vagy ha 2-nél több Stringet akarsz összefűzni.
-
-
válasz
MrSealRD
#3224
üzenetére
Itt nem látok ilyesmit sajnos.
Arról lenne jó valahogy infót szerezni, hogy module projectnél pontosan milyen targetek futnak le és mikor, de egyszerűen nem találok infót róla.
Mert egy sima java project build-impl.xml fájlba látom ezeket a pre/post targeteket, de a module projectébe semmi ilyesmi nincs, mondjuk clean meg release se, mégis lefutnak, szóval nem igazán értem. -
MrSealRD
veterán
válasz
MrSealRD
#2811
üzenetére
Erre valakinek valami ötlete?
Már azt is kipróbáltam, hogy Elindítom a Weblogic-ot és remote server-ként próbálom hozzáadni az Eclipse-hez de semmi.
WLST-n megpróbáltam csatlakozni a futó instance-hoz, (eclispe alól) de egyfolytában elszállt mindenféle kivétellel, hogy nincs szerver.... -
Chipi333
csendes tag
válasz
MrSealRD
#2739
üzenetére
Hát, ha elfogy a hely és új osztályt akarsz betölteni akkor ugyanúgy game over mint ha a heap telne be. A JVM-ek viszont konfigolhatóak, szóval ennek is állítható a mérete, lehet a heap része és ott lehet dinamikus is a mérete, de GC-je nincs feltétlenül, meg hát nem is biztos, hogy szerencsés már betöltött classokat kidobni.
-
Chipi333
csendes tag
válasz
MrSealRD
#2735
üzenetére
Azt nem tudom, hogy ha közben van GC akkor ezeket is gyomlálja e...
A GC a classokat nem gyomlálja. Ezek az adatok nem a Heapen vannak hanem van erre egy külön memóriaterület. Bár úgy tudom, hogy van olyan megoldás is amikor ezt összevonják a heappel, mert pl sok a reflection használat, és nem lehet előre tudni mennyi class lesz betöltve, ellenben para lenne ha futás közben elfogyna itt a hely. -
modder
aktív tag
válasz
MrSealRD
#2669
üzenetére
Én még csak glassfish-t használtam Eclipselinkkel. Weblogic-ban nem vagyok jártas, de
ez a [link] azt sugallja, hogy ez még EJB 1.1, ami már régi, az EJB 2.0 jobban kitalált kevesebb opciót kér.Lehet, hogy a könyv még EJB 1.1-ről beszél, ez esetben szerintem jobban jársz, ha inkább egy on-line tutorial után nézel, ami az újabb verziót tárgyalja
-
modder
aktív tag
válasz
MrSealRD
#2633
üzenetére
Ez úgy hangzott, mintha cinikusan idéztél volna egy 4 évvel ezelőtti cikket
-- de amúgy igazad van részben. még annyival egészíteném ki, hogy ez természetesen nem jelenti azt, hogy bármilyen esetben lecserélhető egy relációs adatbázissal. És még jó darabig sok helyen nem is fogják lecserélni. -
#1809
A szerzetes
csendes tag
MrSealRD
#1808
A szerzetes
csendes tag
-
Löncsi
őstag
válasz
MrSealRD
#1800
üzenetére
4 fajta Layout van.
FlowLayout, BorderLayout, GridLayout,BoxLayout.
Box és FlowLayoutnál mikor átméretezel, a komponens mérete konstans marad.
Szerintem érdemes egy Box-layoutot egy panelre állítani, és egyesével belerakni a komponenseket, így egymás alatt lesznek. (vagy Flow is jó, ekkor egymást követik a komponensek)
Majd ha ezzel megvagy ,magára az ablakra ( getContentPane() )-re kellene tenni egy BorderLayoutot, átadni az előző panelt és "South"-ra tenni, így 'elvileg' egymás alatt/mellett elhelyezkedő konstans méretű gombok lesznek, mindig délen (lent).
De csak tipp így kora reggel, el kell ezzel játszogatni.
-
#1590
Paarthurnax
senior tag
MrSealRD
#1586
Paarthurnax
senior tag
válasz
MrSealRD
#1586
üzenetére
Én az Eclipse EE Developers kiadását használom szinte mindenre. Egy dolgora használtam eddig a Netbeans-t és az GUI tervezés volt, mert tényleg sokkal egyszerűbb abban. Netbeans-t nem ismerem, de ami az Eclipse-ben jó, hogy rengeteg kiegészítőt lehet hozzá letölteni és csak egy pillanat váltani a felületek között és így alkalmas sokféle munkára.
)
Köszönöm! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! Gigabyte B760M i7 12700K 16GB DDR4 512GB SSD RX 6700 XT 12GB Rampage SHIVA Enermax 750W
- ÁRGARANCIA!Épített KomPhone Ryzen 5 5500 16/32/64GB RAM RTX 4060 8GB GAMER PC termékbeszámítással
- AZONNALI SZÁLLÍTÁS Eredeti Microsoft Office 2019 Professional Plus
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest