jeg talte for nylig med en ven om UI-udvikling. Han har også været programmør siden programmering blev betragtet som en arcane kunst (da de af os, der gjorde det, blev betragtet som Gandalf den grå overfor Balrog). Eller måske så vi bare os selv på den måde. Uanset hvad har vi begge været Java-programmører i meget af den tid.
vi beklagede begge, at det var en kontekstskifte at gå fra kodning af de fleste af vores projekter i Java og derefter skulle skifte til JavaScript til frontenden.
baseret på samtaler, jeg har set online, opvarmer flere læsere deres tastaturer for at chide mig for at klage over at skulle kode i JavaScript. Hold dine nøgler kølige, både af os og vores kolleger er erfarne i, og glade for at skrive i, JavaScript og nogen af dens rammer for vores kunder. Men at bruge JavaScript er ikke altid den bedste tilgang.
i dette indlæg introducerer vi to rammer, der giver dig mulighed for at kode din brugergrænseflade i Java: Vaadin og Vaadin.
Hvornår skal du bruge Java til din brugergrænseflade?
samtalen kom tilbage til mig, da jeg talte med en klient — en lille butik med kun et par programmører og en programmør, der også programmerede. De havde besluttet, at de ikke ønskede at opretholde deres projekter på to separate sprog. Deres firma havde standardiseret på Java, og de ønskede at bruge de samme værktøjer og tankegang til at skabe kraftfulde og moderne brugergrænseflader til deres internetapplikationer.
jeg har bemærket på større hold, at holdet ser ud til at adskille sig, nogle foretrækker at koncentrere sig om front-end, og andre arbejder mest på back-end eller server-side kode. Når arbejdet bliver godkendt til udvikling, ser jeg ofte, at de samme programmører enten tager eller får størstedelen af JavaScript-front-end-arbejdet, og andre tager back-end.
jeg siger ikke, at dette er en dårlig ting; faktisk ser det ud til at være det modsatte. Alle ser ud til at være mere produktive i deres komfortområde, men alle er også opmærksomme på, hvad alle andre laver, og kan træde ind i det område, hvis eller når det er nødvendigt. For mindre butikker er dette ikke en mulighed. Ofte vil den samme programmør skrive koden et helt projekt fra brugergrænsefladen til modellen.
heldigvis er der valg, hvis du ønsker at holde din brugergrænseflade på samme sprog som din back-end, hvis det sprog er Java. Lad os tale om et par af dem nu.
Google Toolkit, eller Google Toolkit, er en glimrende mulighed.
jeg har haft stor succes med et projekt, jeg startede for omkring 8 år siden og stadig vedligeholder. GVT tillod mig at opbygge visningslogikken for en enkeltsidet applikation helt i standard Java-kode. Den leveres med et Eclipse-plugin. Jeg brugte det ikke, fordi jeg brugte Netbeans til mit udviklingsmiljø, men da Eclipse er standarden for de fleste hold, kunne dette være meget praktisk.
jeg var i stand til at nedbryde logikken for kontroller (såsom en brugerdefineret tekstboks), i klasser eller hjælpemetoder, ligesom jeg ville forretningslogik på et serversideprojekt. Gennem arv, jeg var i stand til at oprette flere kontroller, der let havde lignende krav. Om det eneste virkelige koncept for forandring, jeg var nødt til at håndtere, var, at brugergrænsefladen er meget mere begivenhedsdrevet end de fleste internettjenester eller anden server-side-kode.
der er to primære ulemper. Den ene er kompileringstiden. Føjer et kompileringstrin til processen, der tager lidt tid. De GVT-klasser, der er bygget i Java, skal kompileres i JavaScript-biblioteker. Jeg har set flere klager over den tid, det tager.
det andet er, at det har været et stykke tid siden GT har set en betydelig opdatering. Fra denne skrivning blev 2.8.2 udgivet for over et år siden i Oktober 2017. Tre år før blev 2.7.0 frigivet, hvilket gør det fire år fra tidspunktet for denne skrivning. Jeg ser indlæg og kommentarer om 3.0 kommer ud, herunder nogle fra to år siden, der spørger, om plakaten skal vente på 3.0 at komme ud, før der implementeres en stor ændring (jeg håber, at plakaten ikke stadig venter), men jeg kan ikke finde nogen tidslinjer for, hvornår den udgivelse kan være ude.
selvom jeg er en stor fan af rammen og anser den for at være moden nok som den er, ved jeg, at denne vaghed i muligheden for fremtidige udgivelser gør nogle projektledere ret nervøse. Ingen ønsker at være bundet til en ramme, der blindgyder på dem.
er et bibliotek, som jeg vil fortsætte med at bruge og foreslå andre hold at bruge, hvis det opfylder deres behov.
Vaadin
Vaadin er en anden god mulighed.
jeg troede oprindeligt, at GT var mit eneste valg til at skrive brugergrænseflader i standard Java-kode. Men da jeg talte med den lille butik, jeg nævnte ovenfor, fortalte de mig, at de havde besluttet at bruge Vaadin til deres projekter. Så, selvfølgelig, jeg var nødt til at tage et kig. Og jeg er imponeret.
jeg vil være ærlig, i skrivende stund har jeg endnu ikke brugt Vaadin til at oprette et projekt. Men jeg ramper op et par personlige projekter, jeg har brug for front-ends til og har til hensigt at bruge dette. Hvis Vaadin lever op til sine løfter, vil det være en perfekt ramme for disse projekter.
Vaadin lover at støtte sprog, der kører i JVM som Kotlin og Scala. Jeg håber, at det inkluderer Groovy. Hvis du læser mange af mine tidligere indlæg, ved du, at jeg er fan af det sprog, fordi du hurtigt kan oprette kode, der let kan vedligeholdes. Dette er vigtige krav for mig, især vedligeholdelse. Intet ødelægger et projekt nede ad vejen mere end ikke at være i stand til let at vedligeholde den kode, der allerede er skrevet.
Afsluttende tanker
du har mange valgmuligheder, når det kommer til brugergrænsefladeteknologi. Uanset om du architecting et projekt eller et produktionsmiljø, du har så mange krav til at huske på.
to krav, du skal huske på, er let udvikling og vedligeholdelighed.
- et udviklingsmiljø, der er vanskeligt at arbejde i, vil resultere i mange omkostningsoverskridelser og gøre bringe nye programmører meget vanskelige.
- et projekt, der er vanskeligt at vedligeholde, vil medføre frustrationer og spilde flere penge i fremtiden.
baseret på dit teams behov og krav er en komplet Java-løsning, fra brugergrænsefladen til modellen, ikke kun mulig, men et godt valg til både hurtig udvikling og nem vedligeholdelse.
tro på god kode.