Een van die lekker kenmerke van 1C:Enterprise-tegnologie is dat die toepassingsoplossing, ontwikkel deur gebruik te maak van bestuurdevorms-tegnologie, in 'n dun (uitvoerbare) kliënt vir Windows, Linux, MacOS X en as 'n webkliënt vir 5 blaaiers bekendgestel kan word - Chrome, Internet Explorer, Firefox, Safari, Edge, en dit alles sonder om die toepassingsbronkode te verander. Boonop funksioneer en lyk en lyk die toepassing in die dun kliënt en in die blaaier byna identies.
Soek 10 verskille (2 prente onder die snit):
Dun kliënt venster op Linux:
Dieselfde venster in die webkliënt (in die Chrome-blaaier):
Hoekom het ons 'n webkliënt gemaak? Om dit ietwat pateties te stel, tyd het so 'n taak vir ons gestel. Werk oor die internet is lank reeds 'n voorvereiste vir besigheidstoepassings. Eerstens het ons die vermoë bygevoeg om via die internet vir ons dun kliënt te werk (sommige van ons mededingers het terloops daar gestop; ander het inteendeel die dun kliënt laat vaar en hulself beperk tot die implementering van 'n webkliënt). Ons het besluit om ons gebruikers die geleentheid te gee om die kliëntopsie te kies wat hulle die beste pas.
Die toevoeging van webgebaseerde vermoëns by die dun kliënt was 'n groot projek met 'n volledige verandering in kliënt-bediener-argitektuur. Die skep van 'n webkliënt is 'n heeltemal nuwe projek, wat van voor af begin.
Probleemstelling
Dus, die projekvereistes: die webkliënt moet dieselfde doen as die dun kliënt, naamlik:
- Vertoon gebruikerskoppelvlak
- Voer kliëntkode uit wat in 1C-taal geskryf is
Die gebruikerskoppelvlak in 1C word beskryf in 'n visuele redigeerder, maar verklarend, sonder pixel-vir-pixel rangskikking van elemente; Ongeveer drie dosyn tipes koppelvlak-elemente word gebruik - knoppies, invoervelde (teks, numeries, datum/tyd), lyste, tabelle, grafieke, ens.
Kliëntkode in die 1C-taal kan bedieneroproepe bevat, werk met plaaslike hulpbronne (lêers, ens.), drukwerk en nog baie meer.
Beide die dun kliënt (wanneer via die web werk) en die webkliënt gebruik dieselfde stel webdienste om met die 1C-toepassingsbediener te kommunikeer. Kliënt-implementerings is natuurlik anders - die dun kliënt is in C++ geskryf, die webkliënt is in JavaScript geskryf.
'N bietjie geskiedenis
Die webkliëntprojek het in 2006 begin, met 'n span van (gemiddeld) 5 mense. Op sekere stadiums van die projek is ontwikkelaars betrek om spesifieke funksionaliteit (sigbladdokument, diagramme, ens.) te implementeer; as 'n reël was dit dieselfde ontwikkelaars wat hierdie funksionaliteit in die dun kliënt gedoen het. Dié. ontwikkelaars het komponente herskryf in JavaScript wat hulle voorheen in C++ geskep het.
Van die begin af het ons die idee van enige outomatiese (selfs gedeeltelike) omskakeling van C++-dunkliëntkode na JavaScript-webkliënt verwerp as gevolg van die sterk konseptuele verskille tussen die twee tale; die webkliënt is van nuuts af in JavaScript geskryf.
In die eerste herhalings van die projek het die webkliënt kliëntkode in die ingeboude 1C-taal direk na JavaScript omgeskakel. Die dun kliënt tree anders op - die kode in die ingeboude 1C-taal word in greepkode saamgestel, en dan word hierdie greepkode op die kliënt geïnterpreteer. Daarna het die webkliënt dieselfde begin doen - eerstens het dit 'n prestasiewins gegee, en tweedens het dit dit moontlik gemaak om die argitektuur van die dun- en webkliënte te verenig.
Die eerste weergawe van die 1C:Enterprise-platform met webkliëntondersteuning is in 2009 vrygestel. Die webkliënt het destyds 2 blaaiers ondersteun - Internet Explorer en Firefox. Die oorspronklike planne het ondersteuning vir Opera ingesluit, maar as gevolg van onoorkomelike probleme op daardie tydstip met die toepassing sluit hanteerders in Opera (dit was nie moontlik om met 100% sekerheid op te spoor dat die aansoek besig was om te sluit nie, en op daardie oomblik die ontkoppelingsprosedure uit te voer vanaf die 1C-toepassingsbediener) van hierdie planne moes laat vaar word.
Projekstruktuur
In totaal het die 1C:Enterprise-platform 4 projekte wat in JavaScript geskryf is:
- WebTools – gedeelde biblioteke wat deur ander projekte gebruik word (ons sluit ook in ).
- Beheer (geïmplementeer in JavaScript in beide die dun kliënt en die web kliënt)
- Beheer (geïmplementeer in JavaScript in beide die dun kliënt en die web kliënt)
- Web kliënt
Die struktuur van elke projek stem ooreen met die struktuur van Java-projekte (of .NET-projekte - wat ook al die naaste is); Ons het naamruimtes, en elke naamruimte is in 'n aparte vouer. Binne die gids is daar lêers en naamruimteklasse. Daar is ongeveer 1000 lêers in die webkliëntprojek.
Struktureel is die webkliënt grootliks verdeel in die volgende substelsels:
- Bestuurde kliënttoepassingskoppelvlak
- Algemene toepassingskoppelvlak (stelselkieslyste, panele)
- Koppelvlak van bestuurde vorms, insluitend, onder andere, ongeveer 30 kontroles (knoppies, verskillende tipes invoervelde - teks, numeries, datum/tyd, ens., tabelle, lyste, grafieke, ens.)
- Objekmodel beskikbaar vir ontwikkelaars op die kliënt (meer as 400 tipes in totaal: bestuurde koppelvlakobjekmodel, data-uitleginstellings, voorwaardelike stilering, ens.)
- Tolk van die ingeboude 1C-taal
- Blaaieruitbreidings (gebruik vir funksionaliteit wat nie in JavaScript ondersteun word nie)
- Werk met kriptografie
- Werk met lêers
- Tegnologie van eksterne komponente, wat dit moontlik maak om in beide dun- en webkliënte gebruik te word
Ontwikkelingskenmerke
Dit is nie maklik om al die bogenoemde in JavaScript te implementeer nie. Miskien is die 1C-webkliënt een van die grootste toepassings aan die kliëntkant wat in JavaScript geskryf is - ongeveer 450.000 XNUMX reëls. Ons gebruik aktief 'n objekgeoriënteerde benadering in die webkliëntkode, wat die werk met so 'n groot projek vergemaklik.
Om die grootte van die kliëntkode te minimaliseer, het ons eers ons eie obfuscator gebruik, en begin met platformweergawe 8.3.6 (Oktober 2014) het ons begin gebruik . Die effek van gebruik in getalle – die grootte van die webkliëntraamwerk na verduistering:
- Eie obfuscator – 1556 kb
- Google Sluitingssamesteller – 1073 kb
Die gebruik van Google Closure Compiler het ons gehelp om die werkverrigting van die webkliënt met 30% te verbeter in vergelyking met ons eie obfuscator. Daarbenewens het die hoeveelheid geheue wat deur die toepassing verbruik word, met 15-25% afgeneem (afhangende van die blaaier).
Google Closure Compiler werk baie goed met objekgeoriënteerde kode, so die doeltreffendheid daarvan vir die webkliënt is so hoog as moontlik. Closure Compiler doen 'n paar goeie dinge vir ons:
- Statiese tipe kontrolering by die projekboustadium (verseker dat ons die kode met JSDoc-aantekeninge dek). Die resultaat is statiese tik, baie naby aan tik in C++ in vlak. Dit help om 'n redelike groot persentasie foute by die projeksamestellingstadium op te vang.
- Verminder kodegrootte deur verduistering
- 'n Aantal optimaliserings van die uitgevoer kode, byvoorbeeld, soos:
- inlynfunksievervangings. Om 'n funksie in JavaScript te roep is 'n redelik duur operasie, en inlynvervangings van gereeld gebruikte klein metodes versnel die kode aansienlik.
- Tel konstantes tydens samestelling tyd. As 'n uitdrukking van 'n konstante afhang, sal die werklike waarde van die konstante daarin vervang word
Ons gebruik WebStorm as ons webkliënt-ontwikkelingsomgewing.
Vir kode-analise gebruik ons , waar ons statiese kode-ontleders integreer. Met behulp van ontleders monitor ons die agteruitgang van die kwaliteit van JavaScript-bronkode en probeer dit voorkom.
Watter probleme het/is ons opgelos?
Tydens die implementering van die projek het ons 'n aantal interessante probleme teëgekom wat ons moes oplos.
Ruil data uit met die bediener en tussen vensters
Daar is situasies waar verduistering van die bronkode kan inmeng met die werking van die stelsel. Kode buite die webkliënt se uitvoerbare kode, as gevolg van verduistering, kan funksie- en parametername hê wat verskil van dié wat ons uitvoerbare kode verwag. Die eksterne kode vir ons is:
- Kode wat van die bediener af kom in die vorm van datastrukture
- Kode vir 'n ander toepassingsvenster
Om verduistering te vermy wanneer ons met die bediener interaksie het, gebruik ons die @expose-merker:
/**
* @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;
}En om verduistering te vermy wanneer ons met ander vensters interaksie het, gebruik ons sogenaamde uitgevoerde koppelvlakke (koppelvlakke waarin alle metodes uitgevoer word).
/**
* Экспортируемый интерфейс контрола 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 (){}Ons het Virtual DOM gebruik voordat dit hoofstroom geword het)
Soos alle ontwikkelaars wat met komplekse web-UI's te doen het, het ons vinnig besef dat die DOM swak geskik is om met dinamiese gebruikerskoppelvlakke te werk. Byna onmiddellik is 'n analoog van Virtual DOM geïmplementeer om werk met die UI te optimaliseer. Tydens gebeurtenisverwerking word alle DOM-veranderinge in die geheue gestoor en slegs wanneer alle bewerkings voltooi is, word die opgehoopte veranderinge op die DOM-boom toegepas.
Optimaliseer die webkliënt
Om ons webkliënt vinniger te laat werk, probeer ons om die standaard blaaiervermoëns (CSS, ens.) tot die maksimum te gebruik. Dus, die vorm-bevelpaneel (geleë op byna elke vorm van die toepassing) word uitsluitlik gelewer met blaaiernutsgoed, met behulp van dinamiese uitleg gebaseer op CSS.
toets
Vir funksionele en prestasietoetsing gebruik ons 'n eie instrument (geskryf in Java en C++), sowel as 'n reeks toetse wat bo-op gebou is .
Ons instrument is universeel - dit laat jou toe om byna enige vensterprogram te toets, en is dus geskik om beide 'n dun kliënt en 'n webkliënt te toets. Die instrument teken die handelinge van die gebruiker wat die 1C-toepassingsoplossing bekendgestel het in 'n scriptlêer aan. Terselfdertyd word beelde van die werkarea van die skerm - standaarde - opgeneem. Wanneer nuwe weergawes van die webkliënt gemonitor word, word skrifte gespeel sonder gebruikersdeelname. In gevalle waar die skermskoot nie by enige stap ooreenstem met die verwysing een nie, word die toets as misluk beskou, waarna 'n kwaliteitspesialis 'n ondersoek doen om te bepaal of dit 'n fout of 'n beplande verandering in die gedrag van die stelsel is. In die geval van beplande gedrag word die standaarde outomaties met nuwes vervang.
Die instrument meet ook toepassingsprestasie met 'n akkuraatheid van tot 25 millisekondes. In sommige gevalle lus ons dele van die skrif (byvoorbeeld deur die bestellinginskrywing verskeie kere te herhaal) om die agteruitgang van uitvoeringstyd oor tyd te ontleed. Die resultate van alle metings word in 'n log aangeteken vir ontleding.
Ons toetsinstrument en toepassing word getoets
Ons instrument en Selenium vul mekaar aan; byvoorbeeld, as een of ander knoppie op een van die skerms sy ligging verander het, sal Selenium dit dalk nie naspoor nie, maar ons instrument sal opmerk, want maak 'n pixel-vir-pixel-vergelyking van die skermskoot met die standaard. Die instrument kan ook probleme met die verwerking van insette vanaf die sleutelbord of muis opspoor, aangesien dit presies is wat dit weergee.
Toetse op beide gereedskap (ons s'n en Selenium) voer tipiese werkscenario's uit ons toepassingsoplossings. Toetse word outomaties van stapel gestuur na die daaglikse bou van die 1C:Enterprise-platform. As skrifte stadiger is (in vergelyking met die vorige bou), ondersoek en los ons die oorsaak van die verlangsaming op. Ons maatstaf is eenvoudig - die nuwe bouwerk moet nie stadiger werk as die vorige een nie.
Ontwikkelaars gebruik verskillende nutsmiddels om verlangsamingvoorvalle te ondersoek; hoofsaaklik gebruik word produksie maatskappy . Logs van die uitvoering van die problematiese bewerking op die vorige en nuwe bouwerk word aangeteken, dan word die logs ontleed. Terselfdertyd is die uitvoeringstyd van enkele bewerkings (in millisekondes) dalk nie 'n deurslaggewende faktor nie - diensprosesse soos vullisversameling word periodiek in die blaaier geloods, dit kan oorvleuel met die uitvoeringstyd van funksies en die prentjie verdraai. Meer relevante parameters in hierdie geval is die aantal JavaScript-instruksies wat uitgevoer word, die aantal atoombewerkings op die DOM, ens. As die aantal instruksies/bewerkings in dieselfde skrif in 'n nuwe weergawe toegeneem het, beteken dit byna altyd 'n daling in prestasie wat reggestel moet word.
Een van die redes vir die afname in werkverrigting kan ook wees dat Google Closure Compiler om een of ander rede nie inlynvervanging van die funksie kon uitvoer nie (byvoorbeeld omdat die funksie rekursief of virtueel is). In hierdie geval probeer ons die situasie regstel deur die bronkode te herskryf.
Blaaier uitbreidings
Wanneer 'n toepassingsoplossing funksionaliteit benodig wat nie in JavaScript beskikbaar is nie, gebruik ons blaaieruitbreidings:
- om met lêers te werk
- om met kriptografie te werk
- werk met
Ons uitbreidings bestaan uit twee dele. Die eerste deel is wat 'n blaaieruitbreiding genoem word (gewoonlik uitbreidings vir Chrome en Firefox geskryf in JavaScript), wat interaksie het met die tweede deel - 'n binêre uitbreiding wat die funksionaliteit wat ons benodig, implementeer. Dit moet genoem word dat ons 3 weergawes van binêre uitbreidings skryf - vir Windows, Linux en MacOS. Die binêre uitbreiding word as deel van die 1C:Enterprise-platform verskaf en is op die 1C-toepassingsbediener geleë. Wanneer dit vir die eerste keer vanaf 'n webkliënt gebel word, word dit na die kliëntrekenaar afgelaai en in die blaaier geïnstalleer.
Wanneer ons in Safari loop, gebruik ons uitbreidings NPAPI; wanneer hulle in Internet Explorer loop, gebruik hulle ActiveX-tegnologie. ondersteun nog nie uitbreidings nie, dus werk die webkliënt daarin met beperkings.
Verdere ontwikkeling
Een van die take vir die webkliëntontwikkelingspan is die verdere ontwikkeling van funksionaliteit. Die funksionaliteit van die webkliënt moet identies wees aan die funksionaliteit van die dun kliënt; alle nuwe funksionaliteit word gelyktydig in beide die dun en webkliënte geïmplementeer.
Ander take sluit in die ontwikkeling van die argitektuur, herfaktorering, die verbetering van werkverrigting en betroubaarheid. Byvoorbeeld, een van die rigtings is verdere beweging na 'n asinchrone werkmodel. Sommige van die funksionaliteit van die webkliënt is tans gebou op 'n sinchrone model van interaksie met die bediener. Die asinchrone model word nou meer relevant in blaaiers (en nie net in blaaiers nie), en dit dwing ons om die webkliënt te verander deur sinchroniese oproepe met asinchrone te vervang (en die kode dienooreenkomstig te herfaktoreer). Die geleidelike oorgang na 'n asynchrone model word verklaar deur die behoefte om vrygestelde oplossings en hul geleidelike aanpassing te ondersteun.
Bron: will.com