Ena od prijetnih lastnosti tehnologije 1C:Podjetje je, da lahko aplikativna rešitev, razvita na podlagi upravljanih obrazcev, deluje tako v tankem (izvršnem) odjemalcu pod Windows, Linux, MacOS X, kot tudi kot spletni odjemalec v 5 brskalnikih – Chrome, Internet Explorer, Firefox, Safari, Edge, vse to pa brez spremembe izvorne kode aplikacije. Poleg tega aplikacija v tankem odjemalcu in brskalniku deluje in izgleda skoraj identično.
Najdite 10 razlik (pod katom 2 sliki):
Okno tanke stranke na Linuxu:
Enako okno v spletnem odjemalcu (v brskalniku Chrome):
Zakaj smo ustvarili spletni odjemalec? Z nekaj patosa lahko rečemo, da je to nalogo postavil čas. Že dolgo je delo preko interneta postalo nujna zahteva za poslovne aplikacije. Na začetku smo dodali možnost dela preko interneta za naš tanki odjemalec (nekateri naši konkurenti so se mimogrede ustavili pri tem; drugi so se, nasprotno, odpovedali tankemu odjemalcu in se omejili na implementacijo spletnega odjemalca). Odločili smo se, da našim uporabnikom omogočimo izbiro tiste možnosti odjemalca, ki najbolje ustreza njihovim potrebam.
Dodajanje možnosti dela preko interneta za tankega odjemalca je bil velik projekt s popolno spremembo arhitekture odjemalec-strežnik. Ustvarjanje spletnega odjemalca pa je povsem nov projekt, ki se je začel iz nič.
Definisanje zadatka
Torej, zahteve za projekt: spletni odjemalec mora delovati enako kot tanki odjemalec, torej:
- Prikazati uporabniški vmesnik
- Izvajati odjemalsko kodo, napisano v jeziku 1C
Uporabniški vmesnik v 1C je opisan v vizualnem urejevalniku, vendar deklarativno, brez natančne razporeditve elementov; uporablja se približno trideset vrst elementov vmesnika – gumbi, vnosi (besedilni, digitalni, datum/čas), seznami, tabele, grafi itd.
Odjemalska koda v jeziku 1C lahko vsebuje strežniške klice, delo z lokalnimi viri (datotekami itd.), tiskanje in še marsikaj drugega.
Tako tanki odjemalec (pri delu preko spleta) kot tudi spletni odjemalec uporabljata isti nabor spletnih storitev za komunikacijo s strežnikom aplikacij 1C. Implementacija pri odjemalcih je seveda različna – tanki odjemalec je napisan v C++, spletni odjemalec pa v JavaScript.
Nekaj zgodovine
Projekt za tvorbo spletnega odjemalca se je začel leta 2006, v povprečju pa je sodelovala ekipa petih oseb. V različnih fazah projekta so bili vključeni razvijalci za izvajanje specifične funkcionalnosti (kot so tabelarni dokumenti, diagrami itd.); običajno so to bili isti razvijalci, ki so realizirali to funkcionalnost v tankem odjemalcu. To pomeni, da so razvijalci znova napisali komponente v JavaScriptu, ki so jih prej ustvarili v C++.
Že na začetku smo zavrnili idejo o kakršni koli avtomatski (čeprav delni) konverziji C++ kode tankega odjemalca v JavaScript spletnega odjemalca zaradi izrazitih konceptualnih razlik med obema jezikoma; spletni odjemalec je bil pisan v JavaScriptu na praznem listu.
V prvih iteracijah projekta je spletni odjemalec konvertiral odjemalsko kodo v vgrajenem jeziku 1C neposredno v JavaScript. Tanki odjemalec ravna drugače — koda v vgrajenem jeziku 1C se prevede v bajtno kodo, ki jo nato interpretira odjemalec. Kasneje je tudi spletni odjemalec začel to početi - najprej je to prineslo zmago v zmogljivosti, drugič - omogočilo je poenotenje arhitekture tankega in spletnega odjemalca.
Prva različica platforme 1C:Podjetje s podporo za spletni odjemalec je izšla leta 2009. Spletni odjemalec je takrat podpiral dva brskalnika - Internet Explorer in Firefox. V prvotnih načrtih je bila vključena podpora za Opero, vendar smo se zaradi neprehodnih težav s procesorji zapiranja aplikacij v Operi (ni bilo mogoče z 100% gotovostjo izslediti, kdaj se aplikacija zapre, in v tem trenutku izvesti postopek odklopa od strežnika aplikacij 1C) morali odpovedati tem načrtom.
Struktura projekta
Skupaj ima platforma 1C:Podjetje 4 projekte, napisane v JavaScriptu:
- WebTools – skupne knjižnice, ki jih uporabljajo drugi projekti (sem spada tudi ).
- Nadzorna komponenta (izvedeno v JavaScriptu tako v tankem kot tudi v spletnem odjemalcu)
- Nadzorna komponenta (izvedeno v JavaScriptu tako v tankem kot tudi v spletnem odjemalcu)
- Spletni odjemalec
Struktura vsakega projekta spominja na strukturo Java projektov (ali .NET projektov – kar je komu bližje); imamo imenske prostore, vsak imenski prostor se nahaja v ločeni mapi. Znotraj mape so datoteke in razredi imenskega prostora. V projektu spletnega odjemalca je okoli 1000 datotek.
Struktura spletnega odjemalca se na splošno deli na naslednje podsisteme:
- Upravljen vmesnik odjemalske aplikacije
- Splošni vmesnik aplikacije (sistemski meniji, panoji)
- Vmesnik upravljanih obrazcev, ki vključuje približno 30 nadzornih elementov (gumbi, različne vrste vnosnih polj – besedilni, digitalni, datum/čas itd., tabele, sezname, grafikone itd.)
- Objektni model, dostopen razvijalcem na odjemalski strani (skupaj preko 400 tipov: objektni model upravljanega vmesnika, nastavitve razporeditve podatkov, pogojno oblikovanje itd.)
- Interpreter vgrajenega jezika 1C
- Razširitve brskalnikov (zagotavljajo funkcionalnost, ki ni podprta v JavaScriptu)
- Delo s kriptografijo
- Delo s datotekami
- Tehnologija zunanjih komponent, ki omogoča njihovo uporabo tako v tankem kot tudi spletnem odjemalcu
Posebnosti razvoja
Izvedba vsega zgoraj opisanega v JavaScriptu – je precej zahtevna naloga. Morda je spletni odjemalec 1C eno največjih odjemalskih aplikacij, napisanih v JavaScriptu – približno 450.000 vrstic. Aktivno uporabljamo objektno usmerjen pristop v kodi spletnega odjemalca, kar poenostavi delo z tako obsežnim projektom.
Za zmanjšanje velikosti odjemalske kode smo najprej uporabili svoj lasten obfuskator, od različice platforme 8.3.6 (oktober 2014) pa začeli uporabljati . Učinek uporabe v številkah – velikost ogrodja spletnega odjemalca po obfuskaciji:
- Lasten obfuskator – 1556 kB
- Google Closure Compiler – 1073 kB
Uporaba Google Closure Compiler nam je pomagala povečati hitrost spletnega odjemalca za 30% v primerjavi z našim lastnim obfuskatorjem. Poleg tega se je za 15-25% (odvisno od brskalnika) zmanjšala količina pomnilnika, ki ga aplikacija zahteva.
Google Closure Compiler zelo dobro deluje z objektno usmerjeno kodo, zato je njegova učinkovitost za spletni odjemalec izjemno visoka. Closure Compiler za nas izvaja več dobrih stvari:
- Statična preverba tipov v fazi zbiranja projekta (to zagotavljamo z označevanjem kode z JSDoc). Na koncu dobimo statično tipizacijo, zelo blizu tipizaciji v C++. To pomaga zajeti precejšen delež napak v fazi prevajanja projekta.
- Zmanjšanje velikosti kode preko obfuskacije
- Vrsta optimizacij izvršilne kode, na primer:
- inline nadomestitve funkcij. Klic funkcije v JavaScriptu je dokaj draga operacija, inline nadomestitve pogosto uporabljenih manjših metod pa znatno pospešijo delovanje kode.
- Štetje konstant v času prevajanja. Če izraz temelji na konstantni vrednosti, bo vanj vstavljeno dejansko stanje konstante.
Kot okolje za razvoj spletnega odjemalca uporabljamo WebStorm.
Za analizo kode uporabljamo , kamor integriramo statične analizatorje kode. S pomočjo analizatorjev spremljamo degradacijo kakovosti izvorne kode v JavaScriptu in si prizadevamo, da do tega ne pride.
Katere naloge smo reševali/rešujemo
Med izvajanjem projekta smo se soočili z vrsto zanimivih nalog, ki smo jih morali rešiti.
Izmenjava podatkov s strežnikom in med okni
Obstajajo situacije, kjer lahko obfuskacija izvorne kode ovira delovanje sistema. Koda, zunanja glede na izvršno kodo spletnega odjemalca, lahko zaradi obfuskacije vsebuje imena funkcij in parametrov, ki se razlikujejo od tistih, ki jih naša izvršna koda pričakuje. Zunanja koda za nas vključuje:
- Koda, ki prihaja s strežnika v obliki strukturiranih podatkov
- Koda drugega okna aplikacije
Da bi se izognili obfuskaciji pri interakciji s strežnikom, uporabljamo oznako @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;
}In da bi se izognili obfuskaciji pri interakciji z drugimi okni, uporabljamo tako imenovane eksportne vmesnike (vmesniki, katerih vse metode so izvozene).
/**
* Экспортируемый интерфейс контрола 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 (){}Preden je bil Virtual DOM splošno sprejet, smo ga že uporabljali)
Kot vsi razvijalci, ki se ukvarjajo s zapletenimi spletnimi UI, smo hitro spoznali, da DOM ni primeren za delo z dinamičnim uporabniškim vmesnikom. Takoj smo uvedli analog Virtual DOM za optimizacijo dela z UI. V času obdelave dogodkov se vse spremembe DOM shranijo v pomnilnik, in šele ob zaključku vseh operacij se akumulirane spremembe uporabijo na DOM drevesu.
Optimizacija delovanja spletnega odjemalca
Da bi naš spletni odjemalec deloval hitreje, se trudimo maksimalno izkoristiti vgrajene možnosti brskalnika (CSS itd.). Tako se nadzorna plošča obrazca (postavljena praktično na vsakem obrazcu aplikacije) risuje izključno s sredstvi brskalnika, z dinamičnim oblikovanjem na osnovi CSS.
Testiranje
Za funkcionalno testiranje in testiranje zmogljivosti uporabljamo orodje lastne izdelave (napisano v Javi in C++), pa tudi niz testov, zgrajenih na osnovi .
Naše orodje je univerzalno – omogoča testiranje praktično vseh namiznih programov, zato je primerno za testiranje tako tankega odjemalca kot tudi spletnega odjemalca. Orodje zabeleži dejanja uporabnika, ki je zagnal aplikacijo „1C“, v datoteko-skripto. Hkrati se posnamejo slike delovnega območja zaslona – etalonov. Pri nadzoru novih različic spletnega odjemalca se skripte predvajajo brez sodelovanja uporabnika. V primeru, da se posnetek zaslona ne ujema z etalonskim v katerem koli koraku, se test šteje za neuspešnega, po čemer strokovnjak za kakovost izvede preiskavo – ali gre za napako ali načrtovano spremembo obnašanja sistema. V primeru načrtovanega obnašanja se etaloni avtomatsko zamenjajo z novimi.
Orodje prav tako meri zmogljivost aplikacij natančno do 25 milisekund. V nekaterih primerih ponavljamo dele skripte (na primer večkrat ponavljamo vnos naročila) za analizo degradacije časa izvajanja skozi čas. Rezultati vseh meritev se beležijo v dnevnik za analizo.
Naše testno orodje in testirana aplikacija
Naše orodje in Selenium se medsebojno dopolnjujeta; na primer, če se je kakšna gumb na enem od zaslonov premaknila, Selenium tega morda ne zazna, a naše orodje to opazi, saj opravi primerjavo zaslona piksel za piksel. Orodje je tudi sposobno zaznati težave z obdelavo vhodov s tipkovnice ali miške, saj jih prav to tudi reproducira.
Testi na obeh orodjih (našem in Selenium) izvajajo tipične delovne scenarije iz naših aplikativnih rešitev. Testi se samodejno izvršijo po dnevni gradnji platforme „1C:Preduzeće“. V primeru upočasnitve izvajanja skript (v primerjavi s prejšnjo gradnjo) izvedemo preiskavo in odpravimo vzrok za upočasnitev. Naš kriterij je preprost – nova gradnja mora delovati vsaj tako hitro kot prejšnja.
Za preiskovanje incidentov upočasnitve izvajanja razvijalci uporabljajo različna orodja; večinoma se uporablja proizvodnje podjetja . Zbirajo se logi izvajanja težavnega postopka na prejšnji in novi različici, nato se logi analizirajo. Pri tem čas izvajanja posameznih operacij (v milisekundah) morda ni odlučno merilo – v brskalniku se občasno izvajajo upravljalni procesi, kot je čiščenje pomnilnika, ki lahko vplivajo na čas izvajanja funkcij in izkrivijo sliko. Bolj relevantni parametri v tem primeru bodo število izvedenih JavaScript instrukcij, število atomarnih operacij nad DOM-om itd. Če se število instrukcij/operacij v istem scenariju v novi verziji poveča – to skoraj vedno pomeni upad zmogljivosti, ki ga je treba odpraviti.
Prav tako lahko ena od vzrokov za upad zmogljivosti povzroči to, da Google Closure Compiler iz nekega razloga ni mogel izvesti inline zamenjave funkcije (na primer, ker je funkcija rekurzivna ali virtualna). V tem primeru poskušamo težavo odpraviti z ponovnim pisanjem izvorne kode.
Razširitve brskalnikov
V primeru, da aplikativni rešitvi manjka funkcionalnost, ki je ne zagotavlja JavaScript, uporabljamo razširitve brskalnikov:
- za delo s datotekami
- za delo s kriptografijo
- delo z
Naše razširitve so sestavljene iz dveh delov. Prvi del – to, kar imenujemo razširitev brskalnika (navadno razširitve napisane v JavaScript za Chrome in Firefox), ki komunicira z drugim delom — binarno razširitvijo, ki implementira potrebno funkcionalnost. Pomembno je omeniti, da pišemo 3 različice binarnih razširitev – za Windows, Linux in MacOS. Binarna razširitev je del platforme 1C:Enterprise in se nahaja na strežniku aplikacij 1C. Ob prvem klicu iz spletnega odjemalca se naloži na odjemalski računalnik in namesti v brskalniku.
Pri delu v Safariju naše razširitve uporabljajo NPAPI, pri delu v Internet Explorerju pa tehnologijo ActiveX. zaenkrat ne podpira razširitev, zato deluje spletni odjemalec z omejitvami.
Daleč razvoj
Ena od skupin nalog za ekipo razvijalcev spletnega odjemalca je nadaljnji razvoj funkcionalnosti. Funkcionalnost spletnega odjemalca mora biti enaka funkcionalnosti
Druge naloge vključujejo razvoj arhitekture, refaktorizacijo, izboljšanje zmogljivosti in zanesljivosti. Na primer, ena od smeri je nadaljnje gibanje proti asinhronemu modelu dela. Del funkcionalnosti spletnega odjemalca je trenutno zasnovan na sinhronem modelu interakcije s strežnikom. Asinhroni model postaja v brskalnikih (in ne le v brskalnikih) vse bolj aktualen in to nas sili, da spremenimo spletnega odjemalca z zamenjavo sinhronih klicev z asinhronimi (in ustrezno refaktorizacijo kode). Postopen prehod na asinhroni model je pojasnjen z nujnostjo podpore za izdane rešitve in njihovo postopno prilagajanje.
Izvor: habr.com
