Një nga karakteristikat e këndshme të teknologjisë 1C:Ndërmarrje është se zgjidhja aplikative e zhvilluar me teknologjinë e formave të menaxhuara mund të ekzekutohet si në klientin e hollë (të ekzekutueshëm) nën Windows, Linux, MacOS X, ashtu si dhe si klient web nën 5 shfletues – Chrome, Internet Explorer, Firefox, Safari, Edge, dhe gjithçka – pa ndryshuar kodin burimor të aplikacionit. Për më tepër – aplikacioni në klientin e hollë dhe në shfletues funksionon dhe duket praktikisht identik.
Gjeni 10 dallime (në fund 2 imazhe):
Dritarja e klientit të hollë në Linux:
Po e njëjta dritare në klientin web (në shfletuesin Chrome):
Pse e bëmë klientin web? Të themi disi me stil, një detyrë e tillë na e dha koha. Që prej kohësh puna përmes Internetit është bërë një kusht i nevojshëm për aplikacionet e biznesit. Në fillim shtuam mundësinë e punës përmes Internetit për klientin tonë të hollë (disa nga konkurrentët tanë, për t'iu përmendur, e ndalën aty; të tjerë, përkundrazi, e braktisën klientin e hollë dhe u kufizuan në realizimin e klientit web). Ne vendosëm t'u ofrojmë përdoruesve tanë mundësinë të zgjedhin atë variant klienti që u përshtatet më mirë.
Shtimi i mundësisë për të punuar përmes Internetit për klientin e hollë ishte një projekt i madh me një ndryshim të plotë të arkitekturës së ndërveprimit klient-server. Krijimi i klientit web ishte një projekt krejtësisht i ri, që filloi nga zero.
Formulimi i detyrës
Pra, kërkesat për projektin: klienti web duhet të bëjë të njëjtën gjë si klienti i hollë, pra:
- Të shfaqë ndërfaqen e përdoruesit
- Të ekzekutojë kodin e klientit, i shkruar në gjuhën 1C
Një ndërfaqe përdoruesi në 1C përshkruhet në redaktorin vizual, por në mënyrë deklarative, pa vendosjen pikë-pikë të elementeve; përdoren rreth tridhjetë lloje elementesh të ndërfaqes – butona, fushat e hyrjes (tekstuale, numerike, datë / kohë), lista, tabela, grafikë etj.
Kodi i klientit në gjuhën 1C mund të përmbajë thirrje nga serveri, punë me burime lokale (skedarë etj.), printim dhe shumë të tjera.
Si klienti i hollë (në punën përmes webit), ashtu edhe klienti web përdorin të njëjtin grup shërbimesh web për komunikim me serverin e aplikacioneve 1C. Implementimi te klientët natyrisht është i ndryshëm – klienti i hollë është shkruar në C++, klienti web – në JavaScript.
Pak histori
Projektin e krijimit të klientit web filloi në vitin 2006, me një ekip të përbërë mesatarisht nga 5 persona. Në faza të veçanta të projektit u angazhuan zhvillues për të realizuar funksionalitete specifike (dokumente tabelarë, diagramë, etj.); zakonisht, këta ishin ata të njëjtët zhvillues që kishin krijuar këto funksionalitete në klientin e hollë. Pra, zhvilluesit shkruanin nga e para në JavaScript komponentët, që më parë i kishin krijuar në C++.
Që në fillim ne hodhëm poshtë idenë e ndonjë konverzimi automatik (edhe nëse pjesor) të kodit të C++ të klientit të hollë në klientin web JavaScript për shkak të ndryshimeve të forta konceptuale midis këtyre dy gjuhëve; klienti web u shkrua në JavaScript nga një faqe e bardhë.
Në iteracionet e para të projektit, klienti web konvertonte kodin e klientit në gjuhën e integruar 1C direkt në JavaScript. Klienti i hollë funksionon ndryshe – kodi në gjuhën e integruar 1C kompilohen në kod bajt, dhe pastaj ky kod bajt interpretohet në klient. Më vonë, klienti web filloi të bënte të njëjtën – së pari, kjo ofroi një fitim në performancë, së dyti, lejoj që të unifikohej arkitektura e klientëve të hollë dhe web.
Versioni i parë i platformës 1C:Ndërmarrje me mbështetje për klientin web doli në vitin 2009. Klienti web atëherë mbështeste 2 shfletues – Internet Explorer dhe Firefox. Në planet fillestare ishte mbështetje për Opera, por për shkak të problemeve të pandreqshme në atë kohë me trajtuesit e mbylljes së aplikacionit në Opera (nuk arrihej me 100% siguri të gjurmohej se kur aplikacioni mbyllej, dhe në atë moment të kryhej procedura e shkëputjes nga serveri i aplikacioneve 1C) nga këto plane duhej të tërhiqeshim.
Struktura e projektit
Në tërësi, platforma 1C:Ndërmarrje ka 4 projekte, të shkruara në JavaScript:
- WebTools – biblioteka të zakonshme, të përdorura nga projektet e tjera (këtë përfshijmë gjithashtu ).
- Element i menaxhimit (implementuar në JavaScript si në klientin e hollë ashtu dhe në klientin web)
- Element i menaxhimit (implementuar në JavaScript si në klientin e hollë ashtu dhe në klientin web)
- Klienti web
Struktura e çdo projekti i ngjan strukturës së projekteve Java (ose projekteve .NET – siç ju përgjigjet); ne kemi hapësira emërtimi, dhe secila hapësirë emërtimi ndodhet në një dosje të veçantë. Brenda dosjes ndodhen skedarë dhe klasa të hapësirës emërtimi. Në projektin e klientit web ka rreth 1000 skedarë.
Strukturalisht, klienti web ndahet në mënyrë të gjerë në nën-sistemat e mëposhtme:
- Ndërfaqja e menaxhuar e aplikacionit klient
- Ndërfaqja e përgjithshme e aplikacionit (menutë sistemore, panelet)
- Ndërfaqja e formave të menaxhuara, duke përfshirë, mes tjerash, rreth 30 elementë kontrolli (butona, lloje të ndryshme fushash hyrëse – tekstuale, numerike, datë/kohë etj., tabela, lista, grafikë etj.)
- Modeli objektor, i disponueshëm për zhvilluesit në klient (përgjithësisht mbi 400 lloje: modeli objektor i ndërfaqes së menaxhuar, konfigurimet e kompozimit të të dhënave, formatimi me kusht etj.)
- Interpreatori i gjuhës së integruar 1C
- Zgjatjet e shfletuesve (përdoren për funksionalitetet që nuk mbështeten në JavaScript)
- Puna me kriptografinë
- Punimi me skedarët
- Teknologjia e komponenteve të jashtme, që lejon përdorimin e tyre si në klientin e hollë, ashtu edhe në klientin web
Veçoritë e zhvillimit
Implementimi i të gjitha asaj që përshkruhet më sipër në JavaScript - është një detyrë e vështirë. Ndoshta, klienti web 1C është një nga aplikacionet më të mëdha client-side të shkruara në JavaScript - rreth 450.000 rreshta. Ne aktivisht përdorim në kodin e klientit web një qasje objektivisht-orientuar, që e thjeshton punën me një projekt kaq të madh.
Për të minimizuar madhësinë e kodit të klientit, në fillim përdorëm obfuskatorin tonë të vet, dhe duke filluar nga versioni i platformës 8.3.6 (tetor 2014) filluam të përdorim . Efekti i përdorimit në numra – madhësia e kuadrit të klientit web pas obfuskimit:
- Obfuskatori ynë - 1556 kB
- Google Closure Compiler - 1073 kB
Përdorimi i Google Closure Compiler na ndihmoi të rrisim performancën e klientit web me 30% krahasuar me obfuskatorin tonë të vet. Përveç kësaj, volumi i memories e përdorur nga aplikacioni është zvogëluar me 15-25% (në varësi të shfletuesit).
Google Closure Compiler punon shumë mirë me kodin objektivisht-orientuar, prandaj efikasiteti i tij pikërisht për klientin web është maksimal. Closure Compiler bën disa gjëra të mira për ne:
- Kontrolli statik i tipeve në fazën e ndërtimit të projektit (sigurohet nga mbulimi i kodit me annotacione JSDoc). Rezultati është një tipizim statik, shumë të afërt me nivelin e tipizimit në C++. Kjo ndihmon të kapim një përqindje të madhe të gabimeve në fazën e kompilimit të projektit.
- Reduktimi i madhësisë së kodit përmes obfuskimit
- Një sërë optimizimesh të kodit të ekzekutueshëm, për shembull, si:
- zëvendësimet në linjë të funksioneve. Thirrja e një funksioni në JavaScript është një operacion relativisht i shtrenjtë, dhe zëvendësimet në linjë të metodave të vogla që përdoren shpesh rrisin ndjeshëm performancën e kodit.
- Numërimi i konstantave në fazën e kompilimit. Nëse shprehja varet nga një konstantë, vlerya reale e konstantës do të vendoset atje.
Si mjedis zhvillimi për klientin në ueb ne përdorim WebStorm.
Për analizën e kodit ne përdorim , ku integrojmë analizatorët statikë të kodit. Me ndihmën e analizatorëve ne monitorojmë degradimin e cilësisë së kodit burimor në JavaScript dhe përpiqemi ta parandalojmë atë.
Cilat detyra kemi zgjidhur/zgjidhim
Gjatë zbatimit të projektit ne u përballëm me një sërë detyrash interesante që duhej të zgjidhnim.
Shkëmbimi i të dhënave me serverin dhe ndërmjet dritareve
Ekzistojnë situata kur obfusikimi i kodit burimor mund të pengojë funksionimin e sistemit. Kodi, i jashtëm ndaj kodit ekzekutiv të klientit në ueb, për shkak të obfusikimit, mund të ketë emra funksionesh dhe parametrash që dallojnë nga ato që kodi ynë ekzekutiv pret. Kod i jashtëm për ne është:
- Kodi që vjen nga serveri në formën e strukturave të dhënash
- Kodi i një dritareje tjetër të aplikacionit
Për të shmangur obfusikimin gjatë ndërveprimit me serverin ne përdorim etiketën @expose:
/**
* @constructor
* @extends {Base.SrvObject}
*/
Srv.Core.GenericException = function ()
{
/**
* @type {string}
* @expose
*/
this.descr;
/**
* @type {Srv.Core.GenericException}
* @expose
*/
this.inner;
/**
* @type {string}
* @expose
*/
this.clsid;
/**
* @type {boolean}
* @expose
*/
this.encoded;
}Dhe për të shmangur obfusikimin gjatë ndërveprimit me dritare të tjera ne përdorim ashtuquajturat interface të eksportuara (interface ku të gjitha metodat janë të eksportuara).
/**
* Экспортируемый интерфейс контрола DropDownWindow
*
* @interface
* @struct
*/
WebUI.IDropDownWindowExp = function(){}
/**
* Перемещает выделение на 1 вперед или назад
*
* @param {boolean} isForward
* @param {boolean} checkOnly
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}
/**
* Перемещает выделение в начало или конец
*
* @param {boolean} isFirst
* @param {boolean} checkOnly
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}
/**
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}Ne përdorëm Virtual DOM para se të bëhej e zakonshme)
Ashtu si të gjithë zhvilluesit që merren me UI-në e komplikuar në web, ne u kuptuam shpejt se DOM-i nuk është përshtatshëm për të punuar me një ndërfaqe dinamike përdoruesi. Praktikisht menjëherë u implementua një analog i Virtual DOM për të optimizuar punën me UI-në. Gjatë trajtimit të ngjarjeve, të gjitha ndryshimet në DOM ruhen në memorje dhe, vetëm pas përfundimit të të gjitha operacioneve, ndryshimet e grumbulluara aplikohen në pemën DOM.
Optimizimi i punës së klientit në web
Për të bërë që klienti ynë në web të funksionojë më shpejt, ne përpiqemi në maksimum të shfrytëzojmë mundësitë standarde të shfletuesit (CSS etj.). Kështu, paneli i komandës së formës (i vendosur pothuajse në çdo formë të aplikacionit) vizatohet ekskluzivisht me mjete të shfletuesit, duke përdorur dizajn dinamik të bazuar në CSS.
Testimi
Për testimin funksional dhe testimin e performancës përdorim një mjet të prodhuar vetë (shkruar në Java dhe C++), si dhe një grup testesh të ndërtuara mbi bazën e .
Mjeti ynë është universal – ai lejon të testoheshin pothuajse çdo program dritare, prandaj është i përshtatshëm për testimin e klientëve të hollë, si dhe për klientët në internet. Mjeti regjistron veprimet e përdoruesit që ka nisur zgjidhjen aplikative "1C", në një skenar skenari. Në të njëjtën kohë, bëhet regjistrimi i imazheve të zonës së punës së ekranit — referencat. Në kontrollin e versioneve të reja të klientit në internet, skenarët ekzekutohen pa pjesëmarrjen e përdoruesit. Në rast se ekrani i shkrepjes nuk përputhet me referencën në ndonjë hap, testi konsiderohet i dështuar, pas së cilës specialisti i cilësisë kryen hetimin — nëse është një gabim apo një ndryshim i planifikuar në sjelljen e sistemit. Në rastin e sjelljes së planifikuar, referencat automatikisht zëvendësohen me të reja.
Mjeti gjithashtu kryen matje të performancës së aplikacioneve me saktësi deri në 25 milisekonda. Në disa raste ne e këto pjesë të skenarit (p.sh., disa herë përsëritim hyrjen e porosisë) për të analizuar degradimin e kohës së ekzekutimit me kalimin e kohës. Të gjitha rezultatet e matjeve regjistrohen në log për analiza.
Mjeti ynë i testimit dhe aplikacioni i testuar
Mjeti ynë dhe Selenium plotësojnë njëri-tjetrin; për shembull, nëse ndonjë buton në një nga ekranet ka ndryshuar vendndodhjen e tij – Selenium nuk mund ta ndjekë këtë, por mjeti ynë do ta vërejë, sepse bën një krahasim pixel për pixel të shkrepjes me referencën. Gjithashtu, mjeti është në gjendje të ndjekë problemet me trajtimin e hyrjeve nga tastiera ose mouse-i, pasi ato janë pikërisht ato që ai përsërit.
Testet në të dy mjetet (tonin dhe Selenium) ekzekutojnë skenarë standard të funksionimit nga zgjidhjet tona aplikative. Testet ekzekutohen automatikisht pas ndërtimit të përditshëm të platformës "1C:Enterprise". Në rast të ngadalësimit të punës së skenarëve (krahasuar me ndërtimin e mëparshëm), ne kryejmë një hetim dhe eliminojmë shkakun e ngadalësimit. Kritëri ynë është i thjeshtë – ndërtimi i ri duhet të funksionojë jo më ngadalë se ndërtimi i mëparshëm.
Për hetimin e incidenteve të ngadalësimit të punës, zhvilluesit përdorin mjete të ndryshme; zakonisht përdoret e kompanisë . Regjistrohen loget e ekzekutimit të operacioneve me probleme në versionin e mëparshëm dhe atë të ri, pastaj loget analizohen. Në këtë rast, koha e ekzekutimit të operacioneve individuale (në milisekonda) mund të mos jetë faktori vendimtar – në shfletues herë pas here nisin procese shërbimi, si pastrimi i mbetjeve, që mund të ndikojnë në kohën e funksioneve dhe të deformojnë imazhin. Parametra më përkatës këtu do të jenë numri i instrukcioneve JavaScript të kryera, numri i operacioneve atomike mbi DOM etj. Nëse numri i instrukcioneve/operacioneve në të njëjtin skenar në versionin e ri është rritur – kjo zakonisht do të thotë një rënie të performancës që duhet të rregullohet.
Gjithashtu, njëra nga arsyet për rënien e performancës mund të jetë se Google Closure Compiler për ndonjë arsye nuk arriti të bëjë zëvendësimin inline të funkcioneve (për shembull, sepse funksioni është rekursiv ose virtual). Në këtë rast, ne përpiqemi të rregullojmë situatën duke riparë kodin burimor.
Zgjatjet e shfletuesit
Në raste kur zgjidhja aplikative ka nevojë për funksionalitete që nuk janë në JavaScript, ne përdorim zgjatjet e shfletuesit:
- për punë me skedarët
- për punë me kriptografinë
- punë me
Zgjatjet tona përbëhen nga dy pjesë. Pjesa e parë është ajo që quhet zgjatje e shfletuesit (zakonisht, zgjatje të shkruara në JavaScript për Chrome dhe Firefox), të cilat ndërveprojnë me pjesën e dytë – një zgjatje binare që realizon funksionalitetin që na nevojitet. Duhet të përmendet se ne shkruajmë 3 versione të zgjatjeve binare – për Windows, Linux dhe MacOS. Zgjatja binare jepet si pjesë e platformës 1C:Enterprise dhe ndodhet në serverin e aplikacioneve 1C. Në thirrjen e parë nga klienti ueb, ajo ngarkohet në kompjuterin e klientit dhe instalohet në shfletues.
Kur punojmë në Safari, zgjatjet tona përdorin NPAPI, ndërsa në Internet Explorer – teknologjinë ActiveX. nuk mbështet zgjatje, prandaj klienti ueb këtu punon me kufizime.
Zhvillimi në vazhdim
Një nga grupet e detyrave për ekipin e zhvillimit të klientit web është avancimi i funksionaliteteve. Funksionaliteti i klientit web duhet të jetë identik me atë të klientit të hollë, të gjitha funksionalitetet e reja implementohen njëkohësisht në të dyja, në klientin e hollë dhe atë web.
Detyra të tjera përfshijnë zhvillimin e arkitekturës, ristrukturimin, përmirësimin e performancës dhe besueshmërisë. Për shembull, një nga drejtimet është lëvizja përpara në modelin e punës asinkron. Një pjesë e funksionalitetit të klientit web aktualisht është ndërtuar mbi modelin e ndërveprimit sinkron me serverin. Modeli asinkron tani po bëhet më i rëndësishëm në shfletues (dhe jo vetëm në shfletues), dhe kjo na detyron të modifikojmë klientin web duke zëvendësuar thirrjet sinkrone me ato asinkrone (dhe duke realizuar përkatësisht ristrukturimin e kodit). Kalimi gradual në modelin asinkron shpjegohet nga nevoja për të mb supportuar zgjidhjet e publikuara dhe përshtatjen e tyre afatshkurtër.
Burimi: habr.com
