Marami na akong naisulat tungkol kay Vaadin . Ako ay naging masigasig kaya sinulat ko ang unang aklat tungkol dito (bukod sa Aklat ni Vaadin), ang na-update na edisyon nito para sa Vaadin 7, at isang kasamang website . Gayunpaman, namangha ako na napakaraming tao sa mundo ng JVM ang hindi nakarinig nito.
Sa post na ito, gusto kong ipakilala si Vaadin sa konteksto ng AJAX at SSR.
Ang kagandahan ng Vaadin ay nakasalalay sa pagiging simple nito - nagsusulat ka lamang ng backend code . Basahin mong mabuti yan. Kailangan lang malaman ng developer ng Vaadin ang Java, o anumang wikang JVM, at ang Vaadin API. Sa runtime, gagawa si Vaadin ng client-side code, ibig sabihin , HTML, JavaScript, at CSS. Ang diskarte na ito ay nagbibigay ng kapangyarihan sa mga developer na tumuon sa pangunahing functionality ng application, na ginagawang mas produktibo ang proseso ng pagbuo.
Bumubuo ang Vaadin sa mga bahagi at layout, tulad ng ginagawa ng mga regular na framework na nakabatay sa desktop. Kung alam mo ang Swing o JavaFX, pakiramdam mo ay nasa bahay ka.
Binanggit ko ang CSS sa itaas: Pinapayagan ka ng Vaadin na bumuo ng iyong CSS sa isang nakalaang magagamit muli na pakete na tinatawag na tema . Ang icing sa cake: ang pagbuo ng isang tema ay maaaring gawin nang kahanay sa pag-unlad ng backend at walang pagsunod sa huli; ang code ay hindi kailangang gumamit ng isang partikular na template o magdagdag ng mga partikular na klase sa HTML.
Ang pag-set up ng Vaadin sa konteksto ng Spring Boot ay madali lang:
<project> <properties> <java.version>17</java.version> <kotlin.version>1.9.24</kotlin.version> <vaadin.version>24.4.9</vaadin.version> <!--1--> </properties> <dependencyManagement> <dependencies> <dependency> <groupId>com.vaadin</groupId> <artifactId>vaadin-bom</artifactId> <!--2--> <version>${vaadin.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>com.vaadin</groupId> <artifactId>vaadin-spring-boot-starter</artifactId> <!--3--> </dependency> </project>
Ang Vaadin ay bubuo sa isang regular na Java Servlet, na nagmamapa sa ugat bilang default. Ang Vaadin Spring Boot integration ay nagbibigay-daan sa pag-override sa default. Dahil ang aming codebase ay nagsasama ng maraming mga frameworks, imapa namin ito sa /vaadin
sa pamamagitan ng nauugnay na property:
vaadin.url-mapping=/vaadin/*
Sa unang kahilingan mula sa isang kliyente, ibabalik ni Vaadin ang code ng JavaScript engine. Ang engine ay gagawa ng mga kasunod na kahilingan upang kunin ang na-configure na UI at scaffold sa huling bahagi ng kliyente. Mula noon, pinangangasiwaan ng engine ang lahat ng pakikipag-ugnayan ng user at ina-update ang UI kung kinakailangan.
Kapag na-set up na namin ang proyekto, dapat naming i-configure kung aling bahagi ang ipinapakita ng Vaadin kapag nakatanggap ito ng kahilingan.
@Route("/") //1 @PageTitle("Vaadin") //2 class TodoView(todos: ArrayList<Todo>) : VerticalLayout() { //3-4-5 init { //6 // ... //7 } }
RootComponent
.VerticalLayout
ay isang klase na nire-render ni Vaadin bilang isang HTML div
init()
function sa unang kahilingan sa browser. Sa snippet sa itaas, namana namin mula sa VerticalLayout
, isang bahaging ibinigay ng Vaadin .
Kasama sa Vaadin Design System ang isang hanay ng mga bahagi na magagamit mo para buuin ang iyong UI. Ang mga bahagi ay may server-side na Java API bilang karagdagan sa TypeScript API para sa client-side development.
Gumagamit ka ng isang bahagi sa pamamagitan ng unang paggawa nito at pagkatapos ay idagdag ito sa isang naglalaman ng layout.
Ang ilang bahagi ay maaaring maglaman ng iba, at alam nila kung paano ilatag ang kanilang mga subcomponents. Halimbawa, inilalagay VerticalLayout
ang mga bahagi mula sa itaas hanggang sa ibaba sa isang hanay; Inilalagay sila HorizontalLayout
mula kaliwa-pakanan sa isang hilera.
Ang pagdaragdag ng mga bahagi sa isang layout ay diretso:
add(Label("Hello")) //1 add(Label("world!"))
init()
function.
Bagama't ito ay gumagana nang perpekto, maaari naming pagbutihin ang sitwasyon gamit ang Karibu-DSL dahil ginagamit namin ang Kotlin. Maaari naming muling isulat ang snippet sa itaas tulad ng sumusunod:
label("Hello") //1 label("world!")
label()
ay isang Karibu DSL extension function sa HasComponent
interface
Mahusay ang Karibu, ngunit may kaunting downside: hindi ito nag-aalok ng mga extension function para sa buong API. Halimbawa, kailangan mong bumalik sa regular na API upang magdagdag ng footer sa isang bahagi Grid
:
appendFooterRow().apply { getCell(completedProp).component = Button("Clean up") { todos.removeIf { it.completed } refresh() } }
Sa karagdagan, ang Karibu ay open-source, at maaari kang mag-ambag anumang oras kung mayroon kang idaragdag.
Ang mga partikular na bahagi na nauugnay sa UI ay hindi mahalaga para sa pangkalahatang pag-unawa. Kung interesado ka, maaari mong suriin ang source code anumang oras.
Kapag ang mga mainframe ay ang mga hari ng computing, na-access mo ang mga ito sa pamamagitan ng mga terminal. Ang UI ay medyo limitado, at ang pag-render ay naganap sa "pipi" na terminal. Inilipat ng mga personal na computer ang pagpapagana ng pag-render mula sa server patungo sa kliyente. Sa oras na ito, ang mga developer ay nag-attach ng gawi sa isang bahagi sa pamamagitan ng trigger. Halimbawa, maaari mong itali ang pag-print ng Hello world!
kapag nag-click ang user sa isang button.
Binago ng mga web application ang paradigma na ito. Gaya ng ipinakita ng aming mga naunang artikulo, ang bawat pakikipag-ugnayan ay nagmamapa ngayon sa isang daloy ng kahilingan-tugon, kasabay o asynchronous. Ibinabalik tayo ni Vaadin sa orihinal na paradigm.
Checkbox(todo.completed).apply { //1 addValueChangeListener { todo.completed = it.value } //2 }
Magsimula ng bagong bahagi Checkbox
na may halaga.
Kapag nagbago ang value ng checkbox, i-execute ang lambda - binabago namin ang value ng pinagbabatayan na modelo.
Hindi na kailangan ng JavaScript code; Malayang pinamamahalaan ni Vaadin ang pakikipag-ugnayan.
Ang post ay isa lamang maikling pagpapakilala kay Vaadin sa konteksto ng AJAX at SSR.
Karamihan sa mga developer na natututo ng programming sa mga web app at sa gayon ay ginagamit sa modelo ng pagtugon sa kahilingan ay hindi maganda ang reaksyon kapag na-expose sa Vaadin. Ang kanilang pangunahing argumento ay ang kawalan ng API. IMHO, ito ay isang benepisyo: ang ilang mga app, partikular na mga app ng negosyo, ay hindi umuunlad sa punto kung saan kakailanganin mong bumuo ng mga nakalaang mobile na kliyente.
Ang Vaadin ay may kasamang default na hanay ng CSS, gaya ng nakasaad sa panimula. Tinitiyak ng default na temang ito na maganda ang hitsura ng mga application ng Vaadin sa simula, na nagbibigay sa mga user ng komportable at kaakit-akit na kapaligiran sa trabaho. Gayunpaman, maaari mong palaging isama ang isa pa o kahit na bumuo ng iyong sarili.
Ang tunay na benepisyo, gayunpaman, ay matatagpuan muli sa antas ng organisasyon. Sa panimulang post, binanggit ko na ang paghihiwalay ng frontend at backend development ay lumilikha ng mga isyu sa panahon ng kanilang pagsasama. Dahil walang ganoong paghihiwalay ang Vaadin, mas predictable ang pagpaplano ng proyekto, dahil walang hakbang sa pagsasama sa pagitan ng front end at back end. Gayundin, ang tema ay maaaring mangyari kaayon ng pag-unlad.
Ang kumpletong source code para sa post na ito ay matatagpuan sa GitHub:
Upang pumunta pa:
Orihinal na nai-publish sa A Java Geek noong ika-13 ng Oktubre, 2024