Jegyzetek a Looking Glass 1-ből. Mobil kliens. Tervezési színkiemelés

A cikk az „A fejlesztés első lépései az 1C-n” ciklusban szerepel. Folytatja az előző cikkben tárgyalt témát, és részletesen ismerteti az 1C:Enterprise 8 platform konfigurátorában megjelent újításokat.

A cikk elolvasása után megtudhatja:

• Mi az a kontextus súgó, és hogyan segít kódíráskor?
• Mire valók a szövegsablonok, és hogyan kell alkalmazni őket a gyakorlatban?
• Miért érdemes kódsor-csoportosítást használni?
• Hogyan javíthatja a kiemelés a kódszerkesztő használhatóságát?
• Milyen kényelmet nyújt az új keresés a konfigurációs fában?
• Hogyan lehet gyorsan megjeleníteni a kívánt alrendszer objektumait?
• Milyen refaktorálási és modalitáscsökkentési eszközök léteznek, és hogyan használja őket?

Alkalmazhatóság

A cikk az 1C:Enterprise platform, 1C 8.3.5 - 8.3.11 kiadások példáján tárgyalja a konfigurátor képességeit, így minden információ naprakész.

Fejlesztések az 1C:Enterprise 8.3 platformkonfigurátorban

Az 1C:Enterprise 8.3 platform új verziójának megjelenésével a fejlesztők több érdekes és hasznos újítással egészítették ki azt, hogy országszerte több száz fejlesztő napi munkáját könnyítsék meg.

Most, amikor egy modul programkódját írjuk a konfigurátor szerkesztőben, a kontextus eszköztipp nem csak az adott kontextusban engedélyezett változók és eljárások neveit jeleníti meg, hanem az éppen szerkesztett eljárás vagy függvény paramétereit is.

Az új funkcionalitás a beépített eljárásokhoz és a fejlesztő saját eljárásaihoz egyaránt elérhető.

A lehetőségek listáját tartalmazó elemleírás így néz ki:

A most megadandó eljárási paraméter félkövéren van szedve. A vízszintes vonal alatt az aktuális paraméter leírása található. Ha kötelező, akkor zárójelben lévő szöveggel van kiemelve.

Ha egy soron belüli eljáráshoz több szintaktikai beállítás is tartozik, a fejlécben nyilak állnak rendelkezésre a beállítások közötti váltáshoz.

Az eljárás- és függvényparaméterek kontextusa a Ctrl + Shift + szóköz billentyűkombinációval hívható meg. Automatikusan is meghívható a „(“ és „, ” karakterek begépelésekor. Ez a viselkedés a konfigurátor beállításai párbeszédablakban engedélyezhető (Eszközök - Beállítások menüpont, Modulok lap - Kontextus tipp):

Az új kontextus eszköztipp másik hasznos funkciója a felhasználó által definiált eljárások és függvények paramétereinek megjelenítése.

Kattintson a képre a nagyításhoz.

Emlékezzünk vissza, hogy van egy dokumentum „Szabványok és módszerek rendszere az 1C: Enterprise 8 platform konfigurációinak fejlesztéséhez”, amely leírja az 1C cég ajánlásait a kifejlesztett programkódhoz.

Így a „Paraméterek” rész egy eljárás (függvény) paramétereit írja le. Ha egyik sem szerepel, a szakasz kimarad.

Megelőzi a „Paraméterek:” sor, majd az összes paraméter leírása egy új sorba kerül. A paraméter leírása új sorban kezdődik, ezt követi a paraméter neve, majd egy kötőjel és a típuslista, majd egy kötőjel és a paraméter szöveges leírása következik.

Például:

// Válaszűrlap készítése egy meglévő e-mailhez.
// Lehetőségek:
// IncomingMail - DirectoryLink.IncomingMails - a megválaszolandó levél.
// OutgoingMail - DirectoryLink.OutgoingMail - űrlapadatok a DirectoryLink.OutgoingMail típushoz,
// a kimenő levélszerkesztő formájában található.
// Szöveg - FormattedDocument - a levél szövegszerkesztő mezője, amely az űrlapon található
// kimenő levelek szerkesztője.
Eljárás Töltse ki a levélre adott választ (bejövő levél, kimenő levél, szöveg) exportálás

A konfigurátor pedig elemzi az ilyen szabályok szerint írt megjegyzéseket, és kontextuális tippet jelenít meg velük!

Kattintson a képre a nagyításhoz.

Az adott formátumnak megfelelő megjegyzés kézi írásának elkerülése érdekében a platform szövegsablonokat biztosít, amelyek a Ctrl + Shift + T billentyűkombináció megnyomásával tekinthetők meg.

Az „Eljárás (címmel)” nevű sablon csak a helyes megjegyzést alkotja.

Ahhoz, hogy ez a sablon működjön, elegendő beírni a „Proc” karaktereket a szerkesztőbe, megnyomni a Ctrl + Q billentyűket, és kiválasztani a kívánt sablont a rendszer által kínált listából.

Kódsorok csoportosítása

A szabványos megoldások moduljai az 1C: Enterprise 8 platformon meglehetősen nagyok, és meglehetősen sok kódsort tartalmaznak.

A programkód olvashatóságának és elemzésének javítása érdekében megvalósult a feltételes és ciklikus utasítások csoportosítása, valamint eljárások.

A 8.3-as platform egy másik lehetőséget biztosít - tetszőleges modulsorokat logikai módon egy csoportba csoportosítani, majd összecsukni, hogy kevesebb helyet foglaljon el a képernyőn a szöveg olvashatóságának javítása érdekében.

Szövegterület kiválasztásához két új előfeldolgozói utasítást vezettek be: #Area és #EndArea.

A programkód végrehajtása során ezeket az utasításokat figyelmen kívül hagyja. Csak a hajtogatás alatt álló kódsorok jelzésére van szükség.

Kattintson a képre a nagyításhoz.

Ügyelni kell arra, hogy a csoportosított területek ne metsszék egymást, mert ebben az esetben nem esnek össze a képernyőn.

A konfigurátorhoz egy szövegsablon került a #Area rövidítésére, amely automatikusan hozzáadja az új terület létrehozására vonatkozó utasításokat a modul szövegéhez.

A konfigurátor beállítások párbeszédablakban (Eszközök - Beállítások menüpont, Modulok - Csoportosítás fül) konfigurálhatja a szövegterületek csoportosítását és hajtogatását.

Tervezési színkiemelés

Most az 1C:Enterprise nyelvű szövegszerkesztőben a szintaktikai konstrukciók, amelyeken a kurzor pillanatnyilag el van helyezve, színesen kiemelve vannak. Például egy eljárás (függvény), egy feltételes utasítás és egy ciklusutasítás eleje és vége:

Kattintson a képre a nagyításhoz.

A platform másik újítása a nyitó- és zárókonzolok kiemelése. Ez nagyon hasznos hosszú kifejezések írásakor, amikor a szintaktikai vezérlő hibát jelez, és a fejlesztőnek meg kell találnia az extra vagy hiányzó zárójelet.

Kattintson a képre a nagyításhoz.

A konfigurátor paraméterei párbeszédablakban (Eszközök - Opciók menüpont, Modulok - Szerkesztés fül) több hasznos konstrukció kiemelését is beállíthatjuk.

Ha kiválasztja a „Jelenlegi azonosító” paramétert, és a szerkesztő háttér színétől eltérő színt rendel hozzá (alapértelmezés szerint fehér), akkor a programkód bármely azonosítójára helyezve a kurzort a program kijelöli. a kiválasztott színt, és ezen felül a modulban előforduló összes azonos azonosító kiemelve lesz, és az azonos azonosítójú karakterlánc-konstansok idézőjelbe tesznek:

Kattintson a képre a nagyításhoz.

Szintén érdekes a „Kiválasztott azonosító” paraméter. Ha olyan szín van beállítva, amely nem egyezik a szerkesztési háttérszínnel, akkor egy azonosítóra duplán kattintva kiemeli azt és az összes megfelelő azonosítót a modul szövegében.

Kattintson a képre a nagyításhoz.

Ha a keresősáv segítségével vagy a Ctrl + F billentyűkombináció lenyomása után keres a modul szövegében, a talált szó kiemelésre kerül, és az összes megtalált szó kiemelésre kerül.

Kattintson a képre a nagyításhoz.

Táblázat dokumentumcellák egyesítése

Korábban a táblázatok dokumentumcelláit csak egy menüponttal vagy a megfelelő parancssor gombjával lehetett egyesíteni.

Most megjelent a Ctrl + M billentyűparancs, megnyomására a táblázatkezelő dokumentum cellái egyesülnek. Az „Összevonás” művelet egy táblázatkezelő dokumentum helyi menüjében is elérhető.

Reméljük, hogy az 1C:Enterprise 8 platform következő kiadásaiban a fejlesztők figyelmet fordítanak a konfigurátorral való munka kényelmének javítására.

Új lehetőségek a fejlesztők számára az 1C:Enterprise 8.3.5-ben

Keressen a konfigurátorban

A konfigurálásnál folyamatosan keresést kell használni. Mindaddig, amíg a konfiguráció viszonylag kevés metaadat objektumot tartalmaz, lehetőség van vizuális keresésre - szemmel, görgetve a konfigurációs fát.

A tipikus konfigurációk azonban meglehetősen terjedelmesek, és ezzel a megközelítéssel a keresés sokáig tart.

A 8.3.5 platform előtt a metaadatfában a következőképpen lehetett keresni:

• írja be az objektum nevét a billentyűzetről, miközben a rendszer úgy keres, hogy a nevet a név első betűjével egyezteti, de csak a konfigurációs fa kiterjesztett soraiban;
• használja a Ctrl + F billentyűkombinációt a keresőablak megnyitásához:

A talált objektumok a Keresési eredmények ablakban jelennek meg, ahonnan duplán kattintva a kívánt metaadat objektumra ugorhat a konfigurációs fában.

A 8.3.5 platform új keresőmezővel rendelkezik a konfigurációs fa felett:

A keresés egy karakterlánc előfordulása alapján történik, amelyet a Név, Szinonim és Megjegyzés konfigurációs objektumok tulajdonságai elemeznek.

Ráadásul a konfigurációs fa „menet közben” szűrésre kerül: csak azok az objektumok maradnak benne, amelyek megfelelnek a beírt szűrőnek.

Nézzük meg, mit jelentenek a színek a szűrő alkalmazása után a fában maradó objektumoknál.

Ha a keresési karakterlánc megtalálható, akkor egy ilyen objektum neve feketével van kiemelve a konfigurációs fában.

Ha ezen felül a keresési karakterlánc szerepel az objektum nevében (nem szinonimában, nem megjegyzésben), akkor az ilyen előfordulások pirossal vannak kiemelve.

Azok az objektumok, amelyek nem illeszkednek a megadott szűrőhöz, de vannak alárendelt (gyermek) objektumai, amelyek megfelelnek a megadott szűrőnek, szürkével vannak kiemelve.

A fenti képen kellékek UserIdIB Könyvtár Felhasználók azért jelenik meg a fában, mert szinonimája a „post” részstringet tartalmazza:

A kereséshez több részstring megadása megengedett, szóközzel elválasztva:

Hasonló keresési karakterlánc jelent meg a kiválasztott objektum tulajdonságait tartalmazó ablakban (tulajdonságok paletta):

A talált tulajdonságok általános listaként, kategorizálás nélkül jelennek meg.

A keresés vagy ingatlannevek, vagy ingatlannézetek alapján történik (a különbség a fenti két képernyőképen látható).

A név/nézet módok között a helyi menü „Tulajdonságnevek megjelenítése” parancsával válthat:

Ugyanez a keresési karakterlánc hozzáadásra került az adattípus kiválasztási ablakhoz:

És a metaadat objektum kiválasztására szolgáló ablakban (például egy információs regiszter kiválasztása, amelyet a számítási regiszter grafikonjaként használnak):

Az egy adott alrendszerben található objektumok gyors megjelenítéséhez a helyi menüben megjelent egy új „Alrendszerobjektumok” elem:

Emlékezzünk vissza, hogyan lehetett ezt elérni a platform korábbi verzióiban.

Meg kellett nyitni az alrendszerek szerinti kiválasztás ablakát, jelölje be a kívánt alrendszer jelölőnégyzetét, törölje az összes többi alrendszer jelölését:

Most gyorsabban elérheti ugyanazt az eredményt. Ezenkívül a választékot leggyakrabban csak egy alrendszerre használják és a legkeresettebbek.

És ezért ez a kis kényelmes innováció időt takarít meg a fejlesztőnek.

A tárolóban rögzített tárgyak gyors megjelenítése

Ha a konfiguráció csatlakozik a tárolóhoz, akkor a Rögzített objektumok gomb elérhető a konfigurációs fa feletti parancspanelen:

A szűrés most közvetlenül a konfigurációs fában történik, nem kell külön ablakot nyitni a tárolóval való munkavégzéshez, szűrőket kell beállítani a rögzített objektumokhoz.

Refaktorálási eszközök

Ha több fejlesztőből álló csoport dolgozik egy konfiguráción, akkor a közös szabványok betartásával figyelni kell a kód érthetőségét.

Ezt nem mindig lehet folyamatosan ellenőrizni, ezért időszakonként dolgoznak a kód olvashatóságának javításán, a már megvalósított töredékek átdolgozásán.

Az ilyen műveleteket kódrefaktorálásnak nevezik. Ez egy program belső szerkezetének megváltoztatásának folyamata anélkül, hogy befolyásolná a külső viselkedését, és azzal a céllal, hogy könnyebben megértsük, hogyan működik.

Ezen túlmenően a fejlesztőknek munkát kell végezniük a konfigurációkban, hogy elhagyják a modalitást - a modális hívások megszüntetését.

Ezért a 8.3.5 platformkonfigurátorban megjelentek a kódrefaktoráló mechanizmusok és eszközök a modális hívásokkal való munkavégzéshez.

Ezek a konfigurátor szövegszerkesztőjének helyi menüjében, egy külön Refaktoring menüben érhetők el.

Kattintson a képre a nagyításhoz.

Nézzük meg közelebbről a megvalósított refaktoráló eszközöket.

1. Válasszon ki egy töredéket

Ez a parancs a kiválasztott kódrészletet külön eljárássá vagy funkcióvá alakítja.

Ha az eljárás, amelyen belül a kijelölés található, fordítási direktívát tartalmaz (&OnClient, &OnServer stb.), akkor a létrehozandó eljárás vagy függvény ugyanazzal a fordítási direktívával fog rendelkezni.

Ha a kiemelt kódrészlet a hozzárendelési utasítás jobb oldalán található, akkor létrejön egy függvény. Vegyünk egy példát. Legyen egy kódrészlet:

&AtClient
Eljárás GoodsItemOnChange(Elem )
Str = ;
Oldal ára = Get ItemPrice(Object.Date , Str.Product );

Vége eljárás

Ha a „Select Fragment” parancsot alkalmazza a kiválasztott kódrészletre, a rendszer a következő programkódot generálja (új funkciót hoz létre):

&AtClient
Eljárás GoodsItemOnChange(Elem )
Str = Items.Products.CurrentData;
Oldal ára = Get ItemPrice(Object.Date , Str.Product );
Str.Sum = CalculateSum(Oldal);
Vége eljárás
&AtClient
Funkció CalculateSum(Str )
Vissza oldal Mennyiség * Oldal ár ;
EndFunctions

A funkció akkor is létrejön, ha a kiválasztott kódrészletben egy változót rendelünk hozzá, amelyet lentebb használunk a kódban. Például:

&AtClient
Eljárás Áruk áraMódosítva(Elem )
Str = Items.Products.CurrentData;
Str.Amount = Str.Quantity * Str.Price ;
Vége eljárás

A kiválasztott terület a következőképpen alakul:

&AtClient
Eljárás Áruk áraMódosítva(Elem )
Str = CurrentLineProducts();
Str.Amount = Str.Quantity * Str.Price ;
Vége eljárás
&AtClient
Funkció CurrentLineProducts()
Változó Str ;
Str = Items.Products.CurrentData
Vissza oldal ;
EndFunctions

2. Átnevezés

Ez a parancs lehetővé teszi egy változó vagy eljárás (függvény) nevének megváltoztatását minden olyan helyen, ahol ténylegesen használják.

Ha egy változó vagy metódus minden előfordulása egyedileg van definiálva, a rendszer új nevet kér, és lecseréli, ahol az azonosító előfordul.

Ha egy változó vagy metódus összes használata nem azonosítható egyértelműen, akkor a rendszer megjeleníti a kérdést és az előfordulásokat:

Vegyünk egy olyan helyzetet, amikor a rendszer nem tudja automatikusan lecserélni az eljárás nevét.

Legyen egy eljárás a dokumentum modulban:

Eljárás Újraszámítás () Exportálás
Az egyes TekStringProducts Az áruciklusból
TekRowProducts.Amount= TekStringProducts.Quantity* TekStringProducts.Price;
EndCycle ;
Vége eljárás

A dokumentum űrlap moduljában pedig a következő kezelő:

&A szerveren
Eljárás RecalculateOnServer()
Dokumentum = PropsFormValue("Egy tárgy" );
Dokumentum.Újraszámítás();
ValueVPropsForm(Dokumentum , „Objektum” );
//további feldolgozás...

Vége eljárás

Egy piros felkiáltójellel ellátott ikon a keresési eredmény ablakában azt jelenti, hogy egyértelműen és pontosan azonosíthatja a használatot az eljárás kódsorában Újraszámítás() a rendszer meghibásodott.

Ennek az az oka, hogy a rendszer nem tudja automatikusan meghatározni a változó típusát. Dokumentum a funkció végrehajtása után FormAttributeToValue().

A környezeti eszköztipp mechanizmus ebben az esetben sem kínál lehetséges opciókat a változó utáni pont megnyomásakor Dokumentum vagy a Ctrl+Szóköz billentyűkombináció megnyomásával.

Kattintson a képre a nagyításhoz.

Az űrlapmodulban lévő eljárások átnevezése újrafaktorálási paranccsal a kezelőreferencia is megváltozik az űrlapelem tulajdonságaiban és parancsaiban.

3. Készítse el a függvény leírását

A parancs megjegyzést hoz létre az eljárás vagy függvény előtt, amelyet a kontextus-súgó mechanizmus megfelelően észlel.

// Eljárás - Töltsön ki egy levelet a sablonnak megfelelően
// Lehetőségek:
// Kimenő levél - -
// Szöveg - -
Eljárás LetterBy sablon kitöltése(Kimenő levél, Szöveg ) Exportálás
//…
Vége eljárás

A rendszer létrehoz egy megjegyzéssablont, amelybe paramétertípusokat és magyarázatokat kell beilleszteni.

Ezután lehetőség lesz a kiterjesztett hint használatára a kód írásakor.

4. Hozzon létre egy riasztásfeldolgozást

Ez a parancs akkor válik elérhetővé a helyi menüben, ha a kurzor egy metódusnévre áll, amelyet egy nyitó zárójel követ.

Ráadásul ezek a módszerek ShowQuestion(),ShowWarning(), ShowInput Numbers()és a modális módszerek egyéb blokkoló analógjai.

Vegyünk egy példát. Kezdjük el írni a kliens parancskezelőt, állítsuk a kurzort a talált metódusra ShowQuestion(), hívja az „Értesítéskezelő létrehozása” parancsot:

&AtClient
Eljárás Töltse ki az anyagokat(csapat)
ShowQuestion (
Vége eljárás
Ennek eredményeként a rendszer a következő programkódot generálja:
&AtClient
Eljárás Töltse ki az anyagokat(csapat)
ShowQuestion (Új LeírásFigyelmeztetések(„FillMaterialsFinish”, ThisObject ));
Vége eljárás
&AtClient
Eljárás Töltse ki az anyagokat Befejezés(EredményKérdés, Extra lehetőségek) Exportálás
Vége eljárás

5. Modális hívás konvertálása

Ez a parancs átalakítja a modális metódust tartalmazó kódrészletet aszinkron megfelelőjére. Nézzünk néhány példát.

Alakítsuk át a hívást a Warning() metódusra:

&AtClient
Eljárás NewHandler()
A = 1;
Figyelmeztetés("Szöveg");
A=2;
Vége eljárás // NewHandler()

A megadott parancs alkalmazása után a programkód a következő formában jelenik meg:

&AtClient
Eljárás NewHandler()
A = 1;
ShowWarning(Új LeírásFigyelmeztetések(„New HandlerCompletion”, ThisObject ),
"Szöveg");
Vége eljárás
&AtClient
Eljárás NewHandlerCompletion(Extra lehetőségek) Exportálás
A=2;
Vége eljárás

Bonyolítsuk le a példát. Fontolja meg egy modális függvény és egy feltételes operátor használatát:

&AtClient
Eljárás NewHandler()
válasz = kérdés(,
Dialógus módKérdés.IgenNem);
Ha Válasz = DialogReturnCode.Igen Akkor
//kitöltési algoritmus
EndIf ;
Vége eljárás

A modális hívás átalakítása után a következőket kapjuk:

&AtClient
Eljárás NewHandler()
Válasz = Undefined ;
ShowQuestion (Új LeírásFigyelmeztetések(„New HandlerCompletion”, ThisObject ),
„A táblázatos rész törlésre kerül. Folytatni?", Dialógus módKérdés.IgenNem);
Vége eljárás
&AtClient
Eljárás NewHandlerCompletion(EredményKérdés, Extra lehetőségek) Exportálás
Válasz = EredményKérdés;
Ha Válasz = DialogReturnCode.Igen Akkor
//kitöltési algoritmus
EndIf ;
Vége eljárás

A kapott töredékben hangsúlyozni kell a Response változó inicializálását.

6. Alakítsa át aszinkron eljárássá

A fent tárgyalt példákban az aszinkron megfelelőikkel rendelkező módszereket átalakításnak vetették alá. Például, Kérdés()És ShowQuestion(), Figyelem()És ShowWarning().

Ha azonban egy modális hívás egy eljáráson belül található, ami viszont egy másik eljáráson belül található, akkor az egész eljáráshívás modális metódussal modális lesz.

Ez azt jelenti, hogy le kell cserélni egy „aszinkron analógra”, csak nem azzal, ami a beépített nyelvben létezik, hanem a saját, kidolgozott módszerünkkel.

Ehhez a „Refaktoring” almenü egy másik parancsa szolgál - „Konvertálás aszinkron eljárássá”. Magyarázzuk el egy olyan eljárás példáján, amely egy másik eljárást hív meg, amelynek belül modális függvénye van:

&AtClient
Eljárás NewHandler()
A = 1;
NestedProcedure();
A=2;
EndProcedure &AtClient
Eljárás NestedProcedure()
Figyelmeztetés("Szöveg");
Vége eljárás

Állítsa a kurzort az eljárás deklarációjára Beágyazott eljárás(), aszinkron eljárássá alakítjuk. A rendszer a következő kódot készíti nekünk:&AtClient
Eljárás NewHandlerCompletion(Eredmény, Extra lehetőségek) Exportálás
Figyelmeztetés = ;
A=2;
ExecuteProcessingAlerts(Éber );
EndProcedure &AtClient
Eljárás NestedProcedure(Figyelmeztetési érték )
Figyelmeztetés("Szöveg");
ExecuteProcessingAlerts(Éber );
Vége eljárás

Ügyeljen a rendszer által hozzáadott módszerre ExecuteNotificationProcessing(), amelyet olyan eljárások megvalósításában használnak, amelyek belsőleg nyithatnak blokkoló ablakokat, de eredményüket vissza kell adniuk a hívó eljárásoknak.

Ne feledje, hogy az aszinkron eljárássá konvertálás azonnali feladata a kiválasztott eljárás hívássorozatának aszinkron formába állítása, de magában az eljárásban található hívások nem változnak.

Ezért a módszer Figyelem() nem cserélték ki. Ezt az aszinkron eljárásra való átalakítás után kell megtenni a „Modális hívás konvertálása” parancs külön meghívásával.

Ha az eredeti kódrészletben a tartalmazó sorban Figyelem(), hajtsa végre a „Modális hívás átalakítása” parancsot, majd a rendszer megkérdezi:

Az eredmény a következő lesz:

&AtClient
Eljárás NewHandler(Figyelmeztetési érték )
A = 1;
NestedProcedure(Új LeírásFigyelmeztetések(„New HandlerCompletion”,
ThisObject, New Structure("Értesítés", Értesítés)));
EndProcedure &AtClient
Eljárás NewHandlerCompletion(Eredmény, Extra lehetőségek) Exportálás
Figyelmeztetés = További lehetőségek.Figyelmeztetés;
A=2;
ExecuteProcessingAlerts(Éber );
EndProcedure &AtClient
Eljárás NestedProcedure(Figyelmeztetési érték )
ShowWarning(Új LeírásFigyelmeztetések(„NestedProcedureCompletion”,
ThisObject , New Structure (“Alert” , Alert )), “Text” );
Vége eljárás
&AtClient
Eljárás NestedProcedure Befejezés ( Extra lehetőségek) Exportálás
Figyelmeztetés = További lehetőségek.Figyelmeztetés;
ExecuteProcessingAlerts(Éber );
Vége eljárás

7. Hozzárendelés egy aszinkron eljáráshoz

Ez a parancs átalakítja a kiválasztott kódrészletet eljárássá vagy funkcióvá, miközben a kiválasztott metódust aszinkron formává alakítja.

Az előző bekezdéstől eltérően ez a parancs „összetett”: először a kiválasztott kódrészlet átkerül egy új eljárásba, amelynek nevét a felhasználó beírja a párbeszédablakban.

Ezután ugyanazokat a műveleteket hajtja végre, mintha a felhasználó jobb gombbal az újonnan létrehozott eljárás címére kattintott volna, majd az Átalakítás aszinkron eljárássá parancsra kattintott volna.

8. Keresse meg a modális modulhívásokat

A fent leírt parancsok egyetlen metódussal vagy egy kiválasztott kódrészlettel működnek.

Olyan eljárásokat valósítottak meg, amelyek a modul egészét dolgozzák fel, például modális hívások keresése a teljes modulon belül.

A talált kódsorok megjelennek a keresési eredmény ablakában:

Kattintson a képre a nagyításhoz.

9. Konvertálja a modális modulhívásokat

Ez a parancs transzformációkat hajt végre a nyitott modulban, de csak azokat a hívásokat, amelyekhez nem szükséges a fejlesztő részvétele.

Szintén a főmenüben található a parancs (Konfiguráció - Refaktorálás - Konfigurációs modális hívások elemzése).

Megkeresi a modális hívásokat is, csak a teljes konfiguráción belül, ellenőrzi, hogy a modális hívások automatikusan konvertálhatók-e.

Kattintson a képre a nagyításhoz.

Következtetés

Végezetül, időrendi sorrendben, röviden megjegyezzük, hogy a konfigurátor milyen további hasznos tulajdonságokkal rendelkezik:

• A modulszövegekben található könyvjelzők listája hozzáadva, amelyek a munkamenetek között menthetők (8.3.6+)
• Dinamikus frissítés esetén nincs szükség a konfigurátor újraindítására, amikor az infobázis kliens-szerver verziójában (8.3.7+) dolgozik.
• Megvalósította az OS X 10.8 és újabb (8.3.7+) rendszerekhez való konfigurációk fejlesztésének lehetőségét. Most már mind a konfigurátor, mind a kliens alkalmazás (vastag és vékony kliensek) elérhető ebben az operációs rendszerben
• Jelentősen kibővült kötegelt módban (8.3.8+) végrehajtható műveletek. Ez nagyban leegyszerűsíti az automatikus konfigurációfrissítési folyamatot.
• Megvalósult az adminisztrációs konzol segédprogram, melynek segítségével a konfigurátor (8.3.8+) indítása nélkül is megoldhatóvá vált néhány infobázissal kapcsolatos probléma.
• Hozzáadott funkcionalitás a bővítmény konfigurációhoz való csatlakoztatásával kapcsolatos problémák ellenőrzéséhez. Korábban nem volt ilyen funkció, és a diagnosztika az üzenetablakban jelent meg a bővítmény csatlakoztatásakor (8.3.9+)
• Bevezetett támogatás a 64 bites konfigurátorhoz. Ez a funkció kiküszöbölte a memóriahiányos problémákat a konfigurációfrissítések és más erőforrás-igényes műveletek során végzett összehasonlítási és egyesítési műveleteknél (8.3.9+)
• Jelentősen felgyorsította a kezelt űrlap első megnyitását a konfigurátorban (8.3.9+)
• Most már részben feltöltheti a szerkesztett konfigurációt XML-fájlokba. Most már csak azokat az objektumokat tudja kirakni, amelyek az utolsó kirakodás óta megváltoztak. Ez jelentősen felgyorsította az XML fájlokba történő exportálást abban az esetben, ha nagy konfigurációkon (8.3.10+) történik módosítás.
• Javítottuk a modulok kombinálásának képességét, figyelembe véve a metódusok elhelyezkedését az előfeldolgozó utasításai által meghatározott területeken (8.3.10+)
• A gyakran használt műveletek sebességének növelése a fejlesztés során (8.3.11).

Ezenkívül a platformfejlesztők kiadásról kiadásra javítják a konfigurátor teljesítményét és ergonómiáját, ezért javasoljuk, hogy lehetőség szerint a jelenlegi kiadások platformján fejlesszen.

Tehát menjünk tovább - a következő cikkben visszatérünk a programozáshoz, és elemezzük a programkód kontextusának fogalmát.

Az utóbbi időben egyre gyakrabban jelentek meg cikkek az 1C-ről a Habrén. alkalmazásfejlesztő környezet. A cikkek inkább fogalmiak, mint alkalmazottak; A szerzők áttekintik az 1C:Enterprise 8 platform egészét, és megpróbálják megérteni, hogy az 1C által kínált üzleti alkalmazások létrehozására szolgáló technológia jó vagy rossz.

Nem foglalkozom azzal, hogy mindegyik szerzőnek igaza van-e vagy sem; Az 1C platformnak, mint minden technológiának, megvannak a maga előnyei és hátrányai. És megvannak a maga érdekességei, saját fejlesztései és mechanizmusai. Erről szeretnék beszélni. És még - szeretnék egy cikket írni az 1C-ről azoknak, akik nem ismerik az 1C-t, egy cikket, amely bemutatja, milyen helyet foglal el az 1C a hasonló szoftvertermékek között. Nekem személy szerint nagyon hiányzott egy ilyen bevezető ismertető cikk, amikor még nem ismertem az 1C-t, de számos más ERP-terméket ismertem.

Szóval, kezdjük!

Mit gyárt az 1C cég?

Azt hiszem, a nagyközönség válaszolni fog erre a kérdésre: "1C: Számvitel". Valaki emlékezni fog az oktatóanyagokra vagy a híres IL-2 Sturmovik játéksorozatra.

A Habr résztvevői természetesen tisztában vannak azzal, hogy az 1C nem csak az 1C: Accounting, hanem az 1C: Enterprise programok egész rendszere, amely magában foglalja az üzleti alkalmazásfejlesztő eszközöket és az ezekkel az eszközökkel létrehozott üzleti alkalmazásokat. Az 1C fejlesztőeszközök segítségével pedig könyvelést, CRM-et és ERP-t írtak (több ezer és több tízezer felhasználó implementációjával), és még sok más.

Az ERP rendszerek a legérdekesebb és legfunkcionálisabb üzleti alkalmazások; Nézzük meg a példájukat, milyen helyet foglalnak el az 1C:Enterprise technológiák az analógok között.

Mik azok az ERP

Mi az ERP rendszerek (és bármilyen üzleti alkalmazás) legértékesebb tulajdonsága? Véleményem szerint ez a rugalmasság, a végfelhasználó üzleti folyamataihoz való alkalmazkodás képessége a lehető legalacsonyabb költséggel.

Nyilvánvaló, hogy egy ERP rendszer programozása során lehetetlen előre látni az üzleti folyamatok összes lehetőségét. A paraméterezés segít; A rendszerbeállításokban a felhasználó (tanácsadó, adminisztrátor) által megváltoztatható paraméterek bevezetésével a rendszer rugalmasságát viszonylag alacsony költséggel növeljük. Az első ERP rendszerek paramétervezéreltek voltak. paraméterekkel konfigurálható.

A paraméterezhető rendszerekben nem minden üzleti esetet lehet előre látni. Ha egy paraméter beállítás nem elegendő, módosítania kell a forráskódot. Itt az ERP-gyártó azzal a kérdéssel szembesül, hogy módosítsa-e a kódot a fogyasztók igényeinek megfelelően, és frissítéseket adjon ki vagy forráskódokban adja meg a rendszert, hogy a felhasználók igényeiknek megfelelően átírhassák a rendszert (ami egyébként nem mentesít a gyártó frissítések kiadásától – a rendszernek fejlődnie kell, támogatnia kell az új funkcionalitást, hogy versenyképes legyen).

Külön kérdés az ERP rendszer írásához szükséges programozási nyelv kiválasztása. Az ERP rendszer nagy része üzleti logika, amelyhez a hagyományos programozási nyelvek, például a C++ nem mindig a legalkalmasabbak. Ideális esetben jó lenne az üzleti logikát olyan magas szintű nyelven programozni, amely maximális kényelmet biztosíthat az üzleti programozónak az üzleti logika írása során, elvonatkoztatva azt az alacsony szintű részletektől (adatbázis jellemzők, fájl I/O és nyomtatási alrendszer, a felhasználói felület ablak alrendszere stb.). Természetesen ebben az esetben ehhez a nyelvhez is létre kell hozni egy fordítót/tolmácsot és egy fejlesztői környezetet.

Van egy mátrixunk a lehetséges kombinációkból:

• nyílt vagy zárt alkalmazáskód (itt nem a szokásos értelemben vett nyílt forráskódra gondolok, hanem az alkalmazás forráskódjának térítés ellenében történő megadásának lehetőségére).
• üzleti logikai programozási nyelv – „normál” (С/Java/Perl/…) vagy speciálisan kifejlesztett, szabadalmaztatott.

Az 1C használatával létrehozott üzleti alkalmazások: A vállalati technológiák olyan nyílt alkalmazásforráskóddal rendelkező rendszerek, amelyek szabadalmaztatott nyelven íródnak, és nincs rövid név; hivatalosan "1C: Enterprise beépített programozási nyelvnek", nem hivatalosan és röviden "1C nyelvnek" hívják.

A modern ERP-piac vezetőinek többsége nyílt forráskódú rendszer. A forráskód „helyben” megváltoztatásának lehetősége óriási rugalmasságot és versenyelőnyt biztosít. A zárt forráskódú termékek más trükkök alkalmazására kényszerülnek; A leggyakoribb lépés a CallBack analógja, amely lehetővé teszi egyéni kód csatolását előre definiált eseményekhez, mind vizuális (űrlap megnyitása és bezárása, kiválasztás értéklistából, ...), mind üzleti eseményekhez (rendelés feldolgozása, számla, ...). Egyes rendszerek képesek saját kezelőket írni C#-ban (vagy más gyakori nyelveken), mások a Microsofttól licencelt Visual Basic for Applications-t stb.

Hogyan szerveződnek az ERP-k?

A nyílt forráskódú alkalmazásokat tartalmazó ERP rendszerek az üzleti logikát megvalósító tényleges forráskódból és ennek az üzleti kódnak a végrehajtási környezetéből (az úgynevezett platformból) állnak.

A platform általában alacsony szintű nyelven (C, C++) íródott, gyakran a platform forráskódja zárva van a végfelhasználók előtt. A platform feladata, hogy lehetővé tegye a programozó számára, hogy elvonatkoztassa az alacsony szintű részletektől (az operációs rendszer és a DBMS jellemzői, stb.), és a tényleges üzleti logika megírására összpontosítson. A platformot gyakran üzleti alkalmazásfejlesztő eszközöknek és rendszeradminisztrációs eszközöknek is nevezik (és egyetértek ezzel a megközelítéssel). Nem nélkülözik egyébként a platformot és egy olyan rendszert, ahol az üzleti logika „hétköznapi” programozási nyelveken van megírva. Ott nem kell értelmezni az alkalmazás kódját, de a platform funkcionalitásának igénye megmarad (például "burkolók" az adatbázis körül vagy egységes hozzáférés a felhasználók listájához és jogaikhoz).

A platform mint üzleti alkalmazás-végrehajtási környezet virtuális gépként írható le. A platformnak általában három fő dolgot kell emulálnia az ERP számára:

• Üzleti logikai végrehajtási környezet.
• Adatbázis.
• Grafikus alrendszer a kliens alkalmazás megjelenítéséhez. Az ügyfélalkalmazás lehet szabványos operációsrendszer-eszközökkel előállított grafikus (beleértve a mobil operációs rendszert is), vagy lehet webes alkalmazás. Webes alkalmazás esetén a platform vagy saját webszervert valósít meg, vagy támogatja a szabványos webszervereket (IIS, Apache stb.)

Elvileg a platform módosításával bármilyen operációs rendszer alatt futtathatóvá tehető a védett nyelven írt ERP, és szinte bármilyen DBMS-ben tárolható az adat. Az ERP-szállítók általában egy vagy két operációs rendszerre és egy vagy két DBMS-re korlátozódnak. A további operációs rendszerek és DBMS támogatása a fejlesztési és tesztelési költségek növekedését jelenti; A termékek új verzióiban az ERP-szállítók gyakran bejelentik bármely DBMS támogatásának megszüntetését.

Az 1C platform az operációs rendszer és a DBMS támogatás tekintetében a következőket kínálja:

• Üzleti logikai végrehajtási környezet: alkalmazáskiszolgálók feladatátvételi fürtje terheléselosztással; OS - Windows vagy Linux
• Adatbázis: saját fájl DBMS (fejlesztéshez és kis telepítésekhez ajánlott), MS SQL, Oracle, IBM DB2, PostgreSQL
• Ügyfél:
  • vékony kliens (csak információ megjelenítése és bevitele az ügyfélen) - Windows és Linux. Működhet alkalmazásszerverrel helyi hálózaton vagy webszolgáltatásokon keresztül (ebben az esetben a Microsoft IIS-t vagy az Apache-t kell telepíteni a szerver oldalon)
  • Webes kliens - a Microsoft IIS vagy Apache szerver oldalán, a kliens oldalon - a négy böngésző bármelyike ​​- Internet Explorer, Chrome, Firefox, Safari
  • vastag kliens (az üzleti logika egy részének végrehajtásával az ügyfélen) - Windows és Linux. Számos korlátozása van (például csak ugyanazon a helyi hálózaton belül működhet az alkalmazáskiszolgálóval). Elavultnak számít, az 1C nem tervezi továbbfejleszteni.
  • Mobil offline kliens (időszakos szinkronizálás lehetőségével) - iOS és Android.

Ha egy 1C program írásakor menedzselt alkalmazástechnológiát használunk (2008 óta elérhető), akkor egy alkalmazáskódból kapunk vékony klienst Windows / Linuxhoz és webes klienst is.

ERP alkalmazásnyelv

Külön téma az üzleti logika megírásának nyelve. Ahhoz, hogy egy üzleti programozó hatékonyan működjön, ennek a nyelvnek a lehető legközelebb kell állnia az üzleti tartományhoz (ideális esetben a DSL-hez, a tartományspecifikus nyelvhez), és távol kell lennie az operációs rendszer és a DBMS technikai részleteitől.

Vegyünk egy tipikus üzleti feladatot: a rendszerbe fel kell adnunk egy új típusú dokumentum (például munkamegrendelés) bevitelének és feldolgozásának lehetőségét. Egy "normál" programozási nyelven írt rendszerben ehhez:

1. Hozzon létre táblázatokat az adatbázisban, ahol a dokumentumra vonatkozó információk tárolódnak.
2. Írjon egy osztályt (vagy osztályokat), amelyek megvalósítják a dokumentummal való munka üzleti logikáját. Az üzleti logika mellett az osztályoknak interakciót is meg kell valósítaniuk az adatbázissal - dokumentumadatok olvasása és írása.
3. Hozzon létre egy felhasználói felületet egy új dokumentumtípus szerkesztéséhez. Gyakran létre kell hoznia egy űrlapot is, amely megjeleníti a dokumentumok listáját, amely lehetővé teszi a keresést különböző mezőkben stb.

Ha C#-n dolgozunk a Visual Studio-ban, akkor minden lépést ugyanabban a fejlesztői környezetben is meg lehet tenni (beleértve az adatbázistervezést is).
Számos szabadalmaztatott nyelvet használó ERP-rendszerben általában ugyanabban a fejlesztői környezetben kell végigvinni a fent leírt három lépést.

Ez a 3 lépés biztosítja a minimumot; de továbbra is létre kell hozni egy felhasználói felületet a bizonylattal való munkavégzéshez, elérhetővé kell tenni a jelentésekben, regisztrálni kell a felhasználók által az új típusú dokumentumokban, a rendszer naplójában (naplójában) végzett változtatásokat stb.

Az 1C-ben a grafikusban le kell írni egy új típusú dokumentum mezőit, és meg kell írni egy kódot, amely a dokumentum-specifikus üzleti logikát valósítja meg (például, hogy melyik számlákra kell írni a dokumentumban áthaladó pénzösszegeket). Minden mást, ami a rendszerben lévő dokumentummal való teljes értékű munkához szükséges, a platform elvégzi:

• Struktúrákat hoz létre a DBMS-ben az adatok tárolására.
• Űrlapok létrehozása egy dokumentum szerkesztéséhez, az ilyen típusú dokumentumok listájának megjelenítéséhez stb. Ha az automatikusan létrehozott űrlapok nem felelnek meg nekünk, elkészítheti saját magát a szabványos űrlapok bővítésével és/vagy megváltoztatásával.
• A dokumentum jelentésekben lesz elérhető.
• A dokumentum és mezői elérhetővé válnak az olvasási/írási jogok elosztására az alkalmazás biztonsági rendszerében.
• A dokumentummezők elérhetővé válnak a teljes szöveges kereséshez az egész rendszerben (figyelembe véve a szinonimákat, az átírási támogatást, a fuzzy keresést stb.).
• Az új típusú dokumentumok minden módosítása naplózásra kerül az alkalmazásnaplóban.
• A rendszer automatikusan metódusokat hoz létre a dokumentum XML-be és JSON-ba való mentésére és olvasására.
• A dokumentum a REST felületen (az OData protokollon keresztül) válik elérhetővé.
• És még sok más

Az 1C fejlesztés sajátossága, hogy körülbelül 20 beépített típusú objektum található a rendszerben, és minden új objektumnak, amelyet a fejlesztő hoz létre, e típusok valamelyikéhez kell tartoznia. A legtöbb ilyen típus a vállalat számviteli tevékenységei körébe tartozó objektumokat ír le - címtárakat, dokumentumokat, számlatükreket stb. Az objektumtípusok másik része technológiai, például web és HTTP szolgáltatások; lehetővé teszik az 1C programok számára, hogy kommunikáljanak a külvilággal.

1C Configurator - alkalmazott megoldások jönnek létre benne. A bal oldalon - egy 1C típusú beépített fa; az egyes ágak alatt - az ilyen típusú alkalmazott objektumok.

Az alkalmazott megoldások fejlesztése a Configuratorban (angol változatban Designer) történik. Nemrég jelent meg az 1C:Enterprise Development Tools eszköz próbaverziója, amely lehetővé teszi az 1C megoldások fejlesztését a népszerű Eclipse környezetben. Az ipari fejlesztés az „1C: Enterprise Development Tools”-ban még nem lehetséges, de ennek a verziónak megfelelően megérthető, hogy a vállalat technológiailag merre halad. Különösen a csapatfejlesztést támogatja a népszerű verzióvezérlő rendszerek (Git, SVN és minden más, amelyhez vannak beépülő modulok az Eclipse-hez); az Eclipse IDE-hez saját beépülő modulokat is írhat, amelyek kiterjesztik a fejlesztői környezet képességeit az 1C-vel való együttműködéshez.

Vállalati fejlesztési eszközök – 1C alkalmazásfejlesztés az Eclipse IDE-ben

Valójában az 1C programozási nyelv szintaxisában leginkább a JavaScriptre hasonlít. A nyelv szigorúan véve nem objektum-orientált. Nincs öröksége; de mivel az összes 1C programobjektum valamelyik beépített objektumtípushoz tartozik, ezt nevezhetjük egyszerűsített öröklődésnek: a beépített objektumtípusok előre meghatározott funkcionalitást valósítanak meg, amelyet az alkalmazásprogramozó újradefiniálhat gyermekobjektumaiban. Az ilyen öröklődés egyszintű, alkalmazásobjektumokból már nem lehet örökölni; az öröklődéshez hasonló megközelítést alkalmaznak a prototípus-programozás (prototípus-alapú programozás) koncepciójában; A JavaScript ennek a koncepciónak az egyik legnépszerűbb képviselője.

Ez a megközelítés szándékosan korlátozza az alkalmazott megoldások kidolgozójának szabadságát, és arra kényszeríti, hogy feladatai megvalósításához a beépített típusok ésszerűen korlátozott palettájáról válassza ki a kívánt típusú objektumot. Cserébe a fejlesztő a platform által megvalósított gazdag funkcionalitást és igazán gyors fejlesztést kap. Ennek a megközelítésnek az előnyei nyilvánvalóak – az 1C számviteli rendszerei könnyen és gyorsan létrehozhatók. Vannak hátrányai is - ha olyan dolgot kell megvalósítania, amelyhez nincs beépített típus a platformon (például SFTP-vel dolgozik), akkor vagy meg kell várnia a platform új verzióját, amelyben ez a funkció működik. implementálva legyen, vagy írja meg saját implementációját „normál” nyelven és hívja meg az 1C-ből a külső komponensek technológiáján keresztül.

Néhány tény a beépített 1C programozási nyelvről:

• Az angol (if…akkor) és az orosz (if…akkor) szintaxis támogatott.
• A nyelv Turing kész.
• Ez egy dinamikusan tipizált nyelv. A változó akkor van társítva egy típushoz, amikor érték van hozzárendelve, nem pedig akkor, amikor a változót deklarálják. Változó deklarálásakor nem lehet megadni a típusát.
  Lehetséges így: var és; a = 1;
  Lehetetlen így: var a as Int; a = 1;
• A DBMS-ből való adatok olvasásához az 1C saját lekérdezési nyelvvel rendelkezik, hasonlóan az SQL-hez. Valójában SQL-re fordítják az 1C programok végrehajtásakor.

Hogyan működik mindez

Hogyan jutnak el az 1C megoldások a végfelhasználókhoz? És hogyan működnek ezek a végfelhasználók számára?

A kérdés teljesebb megválaszolásához emlékeznünk kell az 1C egy jellegzetes tulajdonságára.
Az 1C projektet konfigurációnak nevezzük. A konfiguráció egy teljes önálló program, például könyvelés vagy ERP; tartalmazza az összes objektumot és kódot, amely egy üzleti alkalmazás teljes körű működéséhez szükséges. Az 1C sajátossága, hogy a konfigurációt az adatbázisban tárolják, ugyanabban az adatbázisban, amely magában foglalja az alkalmazás adatait (bejegyzések, könyvtárak és dokumentumok adatai stb.), pl. a program az adatokkal együtt tárolódik. A konfigurációval (és az alkalmazásadatokkal) rendelkező adatbázist az 1C terminológiában infobázisnak nevezik (rövidítve infobázis).

A konfiguráció fájlba tölthető; fájl formájában általában a fejlesztőtől érkezik a végfelhasználókhoz, a kliens rendszeren ez a fájl importálódik az infobázisba. Ezt követően a megoldás használatra kész.

Megoldás architektúra 1C

Hol van telepítve a szoftver:

• DBMS-kiszolgáló – egy vagy több 1C által támogatott DBMS (MS SQL, Oracle, IBM DB2, PostgreSQL). Ha több 1C alkalmazás van telepítve az 1C szerveren, az alkalmazások különböző DBMS-eket használhatnak; például a könyvelés MS SQL, az ERP pedig az Oracle.
• Szerver – egy méretezhető feladatátvevő fürt egy vagy több kiszolgálója. Ide kell telepíteni az 1C Server szoftverterméket (könyvtárak és végrehajtható fájlok készlete). A fürt hibatűrését és méretezhetőségét, valamint a fürt szerverei közötti terheléselosztást az 1C szoftver biztosítja. Egyetlen fürt tartalmazhat Windows és Linux operációs rendszert futtató kiszolgálókat, és egy tartalék fürt is biztosítható a rendszerben.
• Kliens: OS Windows vagy Linux, vékony kliens (1cv8c.exe/1cv8) vagy vastag kliens 1C (1Cv8.exe Windowshoz, 1cv8 Linuxhoz) telepítve kell lennie.
  • A vékony kliens a beépített 1C nyelv korlátozott funkcióinak végrehajtására képes. A beépített nyelvtípusok korlátozott készletén működik, csak a memóriában lévő adatok megjelenítésére és módosítására szolgál. Minden munka az adatbázissal, objektumadatokkal, lekérdezések végrehajtása a szerver oldalon történik. A vékony kliens csak kész, megjelenítésre előkészített adatokat kap.
  • Egy vastag kliens szinte minden olyan funkciót képes végrehajtani, amelyet maga a beépített 1C nyelv biztosít, és csak akkor folyamodik a szerverhez, ha adatokat kell írni vagy olvasni az adatbázisból. Korlátozások: jelentős mennyiségű hardver erőforrást igényel, és csak helyi hálózaton keresztül tud "kommunikálni" az 1C szerverek klaszterével. Elavultnak tekinthető, a visszafelé kompatibilitás miatt támogatott.
• Webszerver - IIS vagy Apache. Az 1C-től - a webszerverek bővítménykészlete telepítve van.
• Webes kliens – a négy támogatott böngésző bármelyike: Internet Explorer, Chrome, Firefox, Safari.
• Mobil kliens: iOS vagy Android és bármely 1C mobilalkalmazás. Az 1C mobilalkalmazás és a szerver közötti kommunikáció módja az adott alkalmazástól függ; leggyakrabban használt web- vagy HTTP-szolgáltatások.

Az 1C összetevői - a szerver, a vékony és vastag kliensek és a webbővítmények - egymás között vagy saját (TCP-n keresztül megvalósított) protokolljukkal, vagy http-n keresztül kommunikálnak.

Mi a különleges az 1C-ben

Miben különbözik az 1C:Enterprise technológia? A fejlesztésszervezés innovatív megközelítésének köszönhetően (erről bővebben lentebb) az 1C:Enterprise két dolgot tesz egyszerűen: a semmiből hozhat létre üzleti megoldásokat, és testreszabhatja a meglévő megoldásokat a végfelhasználók igényeinek megfelelően.

Fejlesztés

A számviteli rendszerek alapvető funkcióit megvalósító beépített objektumoknak köszönhetően egyszerű a semmiből megoldásokat létrehozni. A beépített objektumok jól átgondolt rendszere (és nem egy olyan nyelv, amely általában egy szokásos szkriptnyelv) teszi az 1C:Enterprise-t hatékony eszközzé üzleti alkalmazások létrehozásához. A fejlesztőnek nem kell adatelérési réteget, alap felhasználói felületet stb. írnia. - azonnal egy üzleti probléma megoldására koncentrálhat. Az üzleti problémák megoldására már sokat implementáltak beépített objektumokban (olvasd - alapkönyvtárak) - például hierarchikus címtárak támogatása, számviteli gépek a számvitel és áruelszámolás megvalósításához, mechanizmusok összetett időszakos számításokhoz (például bérszámfejtés) ) és még sok más.

A dobozból a fejlesztő megkapja a platform által megvalósított beépített objektumokat (könyvtárakat, dokumentumokat, regisztereket stb.); ezek minták a számviteli rendszerek világából. Az alkalmazott megoldásban (konfigurációban) a fejlesztő ezeket a mintákat valósítja meg, sajátos üzleti logikával megtöltve.

Az 1C:Enterprise-ben alkalmazott megoldás nem szó szerint programnyelven van megírva. A fejlesztési ideológia két sarokköve a metaadatokból történő fejlesztés (Metadata-driven development) és a modellen alapuló alkalmazás építése (Model-driven development).

Az üzleti alkalmazások metaadatokon alapulnak, amelyek magának az alkalmazásnak a deklaratív leírása. Az alkalmazott megoldás nincs leírva relációs táblákkal, objektumprogramozási nyelvosztályokkal stb., mint a legtöbb rendszerben. Az 1C:Enterprise megoldását metaadatok írják le, egy adott prototípus mintakészletből (könyvtárak, dokumentumok, számlatáblázatok stb.) kiválasztott alkalmazásobjektumok formájában.

A metaadatok objektumok hierarchiáját alkotják, amelyekből az alkalmazásrendszer összes összetevője jön létre, és amelyek meghatározzák a viselkedésének minden aspektusát. Egy üzleti alkalmazás futtatásakor a platform értelmezi a metaadatokat, biztosítva az összes szükséges funkcionalitást.

A metaadatok leírják az adatstruktúrákat, a típusok összetételét, az objektumok közötti kapcsolatokat, viselkedésük és vizuális megjelenítésük jellemzőit, hozzáférési jogok megkülönböztető rendszerét, felhasználói felületét stb. A metaadatok nemcsak arról tartalmaznak információt, hogy mit tárolnak az adatbázisban, hanem arról is, hogy miért ez, ill. hogy az információt tárolják, mi a szerepe a rendszerben, és hogyan kapcsolódnak össze az információtömbök. A programozási nyelv használata elsősorban azon problémák megoldására korlátozódik, amelyek valóban algoritmikus leírást igényelnek (adószámítás, a megadott adatok helyességének ellenőrzése stb.). Az 1C:Enterprise fejlesztési alapelvét röviden így fogalmazhatjuk meg: "Csak ott programozzuk, ahol valóban szükséges, és hagyjuk, hogy a platform elvégezze az összes rutinmunkát."

Az 1C:Enterprise kezdetben egy adott modellen alapuló alkalmazott megoldás kidolgozására irányult. A modell alatt az alkalmazott megoldás felépítésének teljes ideológiáját értjük. Ezek az adatszerkezetek felépítésének módjai, az adatok közötti kapcsolatok típusai, a manipuláció alapelvei, az üzleti logika leírására szolgáló űrlapok, az adatok interfészobjektumokkal való összekapcsolásának módjai, a funkcionalitás rendszerszintek szerinti szétválasztása és még sok más.

Minden üzleti alkalmazás követi az elfogadott modellt, és ez biztosítja viselkedésük egységességét és kiszámíthatóságát. Az a fejlesztő, aki egy adott témakör sajátosságait szeretné tükrözni egy alkalmazott megoldásban, jól meghatározott módszerekkel rendelkezik a probléma megoldására a platformba ágyazott eszközök segítségével. Ez a megközelítés egyrészt korlátozza (értelemszerűen!) a fejlesztő szabadságát, másrészt megóvja a sok hibától, és lehetővé teszi, hogy gyorsan egy működőképes megoldáshoz jusson, amelyet mind saját maga, mind pedig támogathat. , szükség esetén mások által.specialista.

Egyetlen modell jelenléte pozitív hatással van a rendszer egyszerű elsajátítására. Minden fejlesztés egyetlen végponttól végpontig terjedő fogalomrendszer keretein belül, egyetlen adattípus-térben történik. Az egyes objektumok (entitások) metaadataiban található leírás azonnal meghatározza mind a beépített programozási nyelv megfelelő típusait, mind a tárolásukhoz szükséges adatbázis-struktúrákat. Ezen objektumok minden további manipulációja, mind a memóriában, mind az adatbázisban, egységes módon történik, anélkül, hogy szükség lenne a DBMS-sel és az univerzális programozási nyelvekkel végzett munka során használt különféle jelölések közötti akadályok leküzdésére.

Egy kész alkalmazás (konfiguráció), amelyet nyílt forráskódban (például könyvelés vagy ERP) szállítanak egy kliensoldali programozó számára, szinte egy DSL (domain-specifikus nyelv, domain-specifikus nyelv). A programozó kész konfigurációs objektumok (partnerkönyvtár, számlatükör, bérszámfejtés) segítségével módosíthatja a rendszer viselkedését az ügyfél igényeinek megfelelően.

Testreszabás és támogatás

Az alkalmazott megoldás üzleti logikájáról röviden a következőket mondhatjuk: változás alatt áll. Ezt az ügyfél informatikai részlegének munkatársai változtatják meg, a megoldást a vállalkozás üzleti folyamataihoz igazítva. A megoldást pedig a megoldás szolgáltatója módosítja, új funkciókat ad hozzá, támogatja a jogszabályi változásokat és rendszeres frissítéseket tesz közzé.

Az olyan frissítés telepítési eljárása, ahol az üzleti logikát „helyi szinten” módosították az ügyfél igényeinek megfelelően, gyakran nem triviális művelet, amely néha hibákkal is jár. Nagyjából ez a gyártótól származó új alkalmazás forráskódjainak egyesítése egy módosított (a szállító korábbi verziójához képest) ügyfélalkalmazással. Egyrészt meg kell szerezni a frissítéssel együtt járó új funkciókat; másrészt ne veszítse el eredményeit.

Ezt a feladatot mindenki ismeri, akinek egy csapatban kellett dolgoznia ugyanazon az alkalmazáson, és egyesítenie kellett (összevonja) a változtatásait a forráskódban a többi csapattag változásaival. Még ha minden fejlesztő ugyanabban a csapatban dolgozik, és ugyanazokat a szabályokat követi a kód fejlesztése és kódolása során, a források egyesítése néha nehéz feladat lehet. Nos, az ERP rendszerek esetében bonyolítja a helyzetet, hogy a beszállító és a megrendelő fejlesztői különböző szervezetekben dolgoznak, és nem mindig van lehetőségük kommunikálni a kód megértésének nehézségei esetén.

Ne feledje, hogy ha az ügyfél által végrehajtott módosítások túl nagyok, az alkalmazás szállítója úgy gondolhatja, hogy nem nyújt további támogatást a megoldáshoz az ügyfélnél.

A fentiek jelentik az egyik legnagyobb kihívást szinte minden nyílt forráskódú üzleti rendszer életciklusában. Az alkalmazás piaci sikere nagyban függ attól, hogy a szoftvergyártó milyen sikeresen oldja meg ezt a problémát. Az 1C esetében két konfiguráció (szolgáltató és felhasználó) összevonása a frissítés során nem csupán két alkalmazás forráskódjának egyesítését jelenti, hanem mindenekelőtt alkalmazásmodellek egyesítését jelenti, amelynek bizonyos szabályokat be kell tartania. .

A probléma megoldására az 1C kifejlesztett egy támogatási mechanizmust (az 1C: Enterprise platform része), amely lehetővé teszi a megoldásszolgáltató számára, hogy meghatározza, mely konfigurációs objektumokat (könyvtárakat, dokumentumokat stb.) tudja megváltoztatni a kliens, és melyeket nem, azaz. ezek megváltoztatása megzavarja a rendszert, vagy lehetetlenné teszi a szállító további központosított támogatását.

Az ügyfél viszont ezzel a mechanizmussal meghatározhatja a konfigurációja objektumai támogatásának szabályait - például megtagadhatja egy adott objektum beszállító általi támogatását, ha felelősséget vállal az objektum további módosításáért, vagy ha ez az objektum nem szükséges a munkájában. Vagy éppen ellenkezőleg, megtilthatja a "saját" konfiguráció objektumának szerkesztését (még akkor is, ha a szállító ezt engedélyezi), hogy biztosítsa a véletlen változtatásokat.

Ideális esetben kívánatos lenne, ha a felhasználói változtatások a szolgáltató szabványos konfigurációjától eltekintve léteznének, és csak a közvetlen kódvégrehajtás pillanatában szerepelnének a munkában. Ebben az esetben a gyártótól származó frissítések telepítése automatikus folyamattá válik, amely nem igényel emberi beavatkozást. Az 1C két megközelítést kínál, amelyek a testreszabási forgatókönyvek jelentős százalékát fedik le.

Az első megközelítés a külső feldolgozás és a külső jelentések használata. Ezek a mechanizmusok lehetővé teszik további funkciók hozzáadását a rendszer tetejére a konfigurációs forráskód megváltoztatása nélkül. Valójában ezek grafikus felülettel rendelkező szkriptek, amelyek egy adott alkalmazásmegoldáson futnak. Ezek a mechanizmusok eredményezték megfelelőjüket, az "App Store"-t, egy online áruházat, ahol független programozók posztolnak, a végfelhasználók pedig megvásárolják a különböző programokhoz szükséges kiegészítőket.

A második megközelítés, amely viszonylag nemrég jelent meg, a kiterjesztések. A bővítmények által kínált stratégia az, hogy nem kell módosítania az alapértelmezett konfigurációt. Minden változtatás az úgynevezett kiterjesztésben történik, amely valójában szintén konfiguráció (de felhasználói, külön a szolgáltató konfigurációjától). Ugyanakkor a frissítés telepítése a gyártótól automatikus lesz - a támogatási mechanizmus szempontjából a szabványos konfiguráció nem változott. És a végső konfiguráció (amely egy tipikus konfiguráció és egy kiterjesztés kombinációja) működése során a kiterjesztésben hozzáadott (vagy módosított) objektumok lesznek érintettek.

Mi más?

Mi még érdekes / fontos az 1C technológiai vonalon? A lista tartalmazza a legjelentősebb mechanizmusokat, amelyek mindegyike külön cikkben (vagy többben) tárgyalható:

• Felhőmegoldás Az 1cFresh egy „felhő a dobozból”, egy vízszintesen méretezhető környezet az 1C-alkalmazási megoldásokkal (és partnercégekkel) való együttműködéshez szolgáltatási modellben (SaaS). A termék tartalmazza az SaaS működéséhez szükséges összes funkciót - regisztráció és felhasználókezelés, új alkalmazásmegoldások gyors közzététele, felhasználói adatok biztonsági másolatainak elkészítése stb. Az 1C cég maga is az 1cFresh terméket használja termékei bérlésére (http://1cfresh.com), és az 1cFresh megoldást dobozos termékként is értékesíti, így a partnerek és ügyfelek saját felhőket telepíthetnek az 1C alapú alkalmazásmegoldásokhoz. : Vállalati technológiák.
• 1C mobilplatform (fent említettük), amely lehetővé teszi, hogy egyetlen forráskódból alkalmazásokat hozzon létre mobil operációs rendszerekhez (iOS, Android) ugyanazzal a módszertannal és fejlesztői környezettel (Configurator), mint a "szokásos" 1C alkalmazásoknál.
• Erőteljes és rugalmas jelentési rendszer. A jelentések rendkívül fontos mechanizmusok minden üzleti rendszerben; sok ERP más gyártók külső jelentéskészítőit használja, mint pl egy jó jelentéskészítő létrehozása nem könnyű feladat speciális specifikációkkal. Az 1C-ben a jelentések ugyanabban a környezetben (Configurator) készülnek, mint maga az alkalmazás; A jelentéstételi mechanizmus az adatösszetételi rendszeren (DCS), a jelentések deklaratív leírásának mechanizmusán alapul. Az 1C jelentéseinek egyik fontos jellemzője, hogy a végfelhasználó a fejlesztő által készített jelentést „maga számára” módosíthatja, ugyanazokat a jelentéstervezési lehetőségeket használva, mint a fejlesztő.
• Adatcsere mechanizmus, amely lehetővé teszi földrajzilag elosztott információs rendszerek létrehozását, amelyek offline, állandó kapcsolat nélkül cserélnek adatot. Az adatcsere az 1C: Vállalati alkalmazások és az 1C: Vállalati alkalmazások és harmadik féltől származó rendszerek között egyaránt lehetséges.
• És még sok érdekesség

1C: Enterprise – technológiák és eszközök

Konklúzió helyett

Remélem, hogy azoknak az olvasóknak, akik nem ismerik az 1C-t, többé-kevésbé tiszta képük lesz arról, hogy mi az 1C, hogyan működik és milyen lehetőségeket kínál a fejlesztőknek. Sok érdekes téma kívül esik az áttekintésen; róluk legközelebb.

Az 1C az 1990-es évek közepén az alkalmazásarchitektúra platform-orientált megközelítését választotta. A nagy teljesítményű platform és az ésszerűen korlátozott alkalmazásnyelv ez a különleges kombinációja jól megmutatta magát – több mint 1000 hivatalosan tanúsított 1C megoldást hoztak létre az 1C technológiákon különböző üzleti területekre, a kisvállalkozások automatizálásától a több ezer egyidejű felhasználóval rendelkező vállalatirányítási rendszerekig. Címkék hozzáadása

Kedves és szeretett vásárlóink, igyekszünk jobbakká válni az Ön számára!

Ezzel kapcsolatban megkezdjük az átalakítást Központ szépség a Tulskayán július 15-től. A felújítás 2 hétig tart. A felújított és korszerűsített központ július 29-én nyitja meg kapuit előttetek.

Ebben az időszakban örömmel látjuk Önt a Kantemirovskaya központjában, valamintszeretnénk tájékoztatni Önt, hogy a Tulskaya néhány szakembere a Kantemirovskaya-nál fog dolgozni a javítás során.

Elnézést kérünk az okozott kellemetlenségért.

Több információTisztázhatodegyetlen CALL központban+7 495 134 22 22.

Iratkozzon fel a mi Instagramés kövesse a folyamatot, érdekes lesz!

Kriolipolízis - ÚJ!!!

ELŐNYÖK A 54 400*!

Abszolút ütés EURÓPAI KLINIKÁK -CRYOLIPOLIS COCCON :

✔️ FÁJDALOMMENTES;

✔️ GYORS EREDMÉNY;

​ ✔️ A ZSÍRSZÖVET EGYSÉGES CSÖKKENTÉSE;
✔️ NINCS MELLÉKHATÁS;
✔️ SZÉLES ALKALMAZÁSI TERÜLET - A hastól és a combtól az állig.

*A promócióval kapcsolatos további információkért forduljon a rendszergazdákhoz, vagy hívja.

Forradalmi PRX-T33 emulzió MOST VELÜNK!

A PRX-T33 egy egyedülálló szabadalmaztatott termék, amely forradalmasította a kozmetológiát Olaszországban, és 10 éves klinikai vizsgálatok után belépett az orosz piacra. PRX-T33 - kémiai peeling a bőr revitalizálására (fiatalítására). Eljárás szabályozott bőrkárosodások serkentésére és helyreállítására, anélkül, hogy károsítaná a hámréteget, anélkül, hogy hámlást okozna. A legtöbb hámozást az őszi-téli időszakban javasolt elvégezni, de PRX-T33 - egész szezonban.

ÚJ FODRÁSZ!

Most a hálózati központokban szépség "Through the Looking Glass" (metró Kantemirovskaya, metró Tulskaya) megjelentek a borbélyok - ezek olyan mesterek, akikre a modern ember nyugodtan rábízhatja arculatát: fodrászatot, bajusz-, szakállformázást vagy királyi borotválkozást. A fodrász segít kiválasztani a hajápolást és hajformázást, javasolja a megjelenés típusának és a tökéletes szakállnak megfelelő formázást. A férfiak számára készült frizurák széles választékban vannak. Egy hajvágású fiatalember ki tudja fejezni jellemét, hangulatát, arculatát!Válassza ki életmódját!

Babor - "A megtisztulás művészete"

A "Through the Looking Glass" szépségápolási központokban megjelent egy új otthoni kozmetikai termékcsalád - "The Art of Cleansing", a német Babor cégtől.
A sor a következőket tartalmazza:
Tisztító enzimpor, bőrtisztító trió szett, gyengéd peeling, termálvizes tonik esszencia, rózsavíz tonik esszencia, tisztító tej.

A tökéletes manikűr Luxio-val most a Kantemirovskaya Looking Glass-jában található

Szépségszalon a szemüvegen keresztül bemutatja a manikűr és pedikűr modern vonalát - LUXIO.

Ez a cikk egy új funkció bejelentése.
Nem ajánlott a cikk tartalmát új funkciók megismerésére használni.
Az új funkciók teljes leírását a megfelelő verzió dokumentációja tartalmazza.
Az új verzió változásainak teljes listája a v8Update.htm fájlban található.

Verzióban megvalósítva8.3.12.64 mobil platform.

Új technológiát vezettünk be - egy mobil klienst. Lehetővé teszi olyan alkalmazások létrehozását mobil eszközökhöz, amelyek egy mobil platform felhasználóbarát felületét és az online munkát egy infobázissal kombinálják, hasonlóan a vékonykliensekhez.

Mobil munka forgatókönyvek

Egészen a közelmúltig az 1C:Enterprise platform kínálta az egyetlen olyan technológiát, amellyel mobileszközökön keresztül lehetett dolgozni alkalmazásaival. Ez egy mobil platform.

Ez a technológia lehetővé teszi speciális off-line mobil alkalmazások létrehozását kényelmes és funkcionális mobil felülettel. A mobilalkalmazásokat konkrét mobilfeladatok megoldására fejlesztik, azokra optimalizálva, amennyire csak lehetséges architektúra és felület szempontjából. Az ilyen alkalmazások pontosan mobil munkavégzési forgatókönyveket valósítanak meg, kényelmes velük dolgozni táblagépen és okostelefonon is.

Architektúrájukban az ilyen alkalmazások nagyon hasonlítanak az 1C:Enterprise rendszer fájlverziójához. A mobileszköznek saját adatbázisa van, a mobilalkalmazásban "belül" van egy kliens, amely interakciót biztosít a felhasználóval, és egy szerver, amely interakciót biztosít az adatbázissal.

Az ilyen mobilalkalmazások kölcsönhatásba léphetnek az irodában telepített „fő” alkalmazással. De ez nem online interakció, hanem időszakos adatcsere a háttérirodával. A mobilalkalmazásban a fő munka offline módban történik. És amikor megjelenik az internetkapcsolat, az adatok szinkronizálódnak.

Így a mobilplatform kiválóan alkalmas autonóm munkahelyek kialakítására a cégen kívüli, az irodához megbízható internetkapcsolattal nem rendelkező munkavállalók számára. Ezeknek a munkaállomásoknak azonban általában korlátozott a funkcionalitása, kevesebb, mint a "fő" alkalmazásé. Ezenkívül nem biztosítanak online interakciót az információs bázissal.

Kiderül, hogy a feladatok jelentős körét nem fedi le, ami a következő jellemzőkkel rendelkezik:

• Az információs bázissal való interakciót online kell végrehajtani;
• Mobileszközön a "fő" alkalmazásmegoldás összes funkciójának elérhetőnek kell lennie, még akkora is, mint például az "1C: ERP Enterprise Management";
• A felületnek kényelmes munkát kell biztosítania bármely mobileszközön, bármilyen képernyőmérettel és helyen.

Mobil kliens

A problémák ezen osztályának megoldására kifejlesztettünk egy mobil klienst. A mobilkliens egy vékony kliens mobileszközökhöz, amely a mobilplatformhoz hasonló felülettel rendelkezik. A mobilkliens disztribúciós készlet tartalmazza az összes szükséges futtatható fájlt, amelyekből a fejlesztő ugyanúgy készíthet alkalmazást egy mobileszközre, ahogyan a mobilalkalmazásokat mobilplatformról építik.

Egy ilyen alkalmazás egyrészt közvetlenül kommunikálhat egy 1C:Enterprise szerverfürttel, ugyanúgy, mint egy vékony kliens. Másrészt a mobil kliens biztosítja a konfigurációban deklaratívan leírt űrlapok automatikus átalakítását a mobil platformhoz hasonló felületté.

Az 1C:Enterprise asztali verziójához kifejlesztett űrlapok automatikusan úgy vannak elrendezve, hogy elfogadható szinten biztosítsák a velük való munkavégzés kényelmét a mobiltelefonok kis képernyőjén.

Természetesen ahhoz, hogy ez az átalakítás még jobban megvalósuljon, meg kell adni néhány új űrlapelem tulajdonságot kifejezetten a mobil kliens számára, meg kell szabadulni néhány speciális és nem szabványos interfész megoldástól. Vagyis az alkalmazott megoldás bizonyos feldolgozása kifejezetten mobil kliens számára szükséges. De ez az újratervezés sokkal könnyebb, mint egy dedikált, teljes funkcionalitású mobilalkalmazás elkészítése.

Potenciális felhasználók

Véleményünk szerint erre a technológiára azokban a megvalósításokban lesz kereslet, amelyek mobileszközökről online hozzáférést igényelnek a rendszerhez. Így a mobileszközön bevitt adatok a közbenső szinkronizálási lépéseket megkerülve közvetlenül a „közös” adatbázisba kerüljenek.

Ezenkívül a mobil kliensre olyan kis cégeknél lesz kereslet, amelyeknek sem költségvetésük, sem idejük nincs speciális mobilalkalmazások fejlesztésére. Becsléseink szerint ugyanis a mobilalkalmazások fejlesztésének legnehezebb szakasza az adatcsere-rendszer létrehozása.

Ezenkívül a mobil kliens hasznos lesz az 1Сfresh technológián alapuló szolgáltatások felhasználói számára. Ezek az 1Cfresh.com és az 1C által támogatott számviteli szolgáltatások, valamint az ezzel a technológiával telepített egyéb szolgáltatások.

Funkcionalitás

Ha összehasonlítjuk a mobil kliens funkcionalitását azzal, amit egy vékony kliens „meg tud csinálni”, akkor ennek nemcsak korlátai vannak, hanem előnyei is.

A mobil kliens fontos előnye, hogy tartalmazza a mobilplatform összes, az eszközök által meghatározott funkcionalitását. Vagyis lehetővé teszi például a fényképek készítését, az előfizetői szám tárcsázását, a PUSH üzenetek fogadását és még sok mást.

A mobil kliens másik előnye, hogy nem csak a szerver verziójával működik, amelyre készült. A szerver szinte bármely verziójával működik, amíg nem történik jelentős változás az Exchange protokollban vagy a platform architektúrában. Ezt azért tettük, mert a mobilalkalmazások publikálása meglehetősen munkaigényes és hosszadalmas folyamat, amelyet szinte lehetetlen végrehajtani egy szerverfürt platform új verziójára való átvitelével egyidejűleg.

Ha már korlátokról beszélünk, ezek közül a legnyilvánvalóbb, hogy a mobil kliens csak a HTTP (HTTPS) protokollon keresztül lép kapcsolatba a szerverfürttel.

Egy másik korlát azonban a mobilplatform esetében a beépített nyelv egyes objektumainak és egyes interfészelemeinek elérhetetlensége. De megpróbáljuk minimalizálni ezeket a különbségeket, ahogy a mobil kliens fejlődik.

Űrlapfelület-építés automatizálása

A mobil kliens létrehozásakor nagy figyelmet fordítottunk arra, hogy a konfiguráció mobil kliensre való adaptálása minimális erőfeszítést igényeljen. Számos technológiát és megközelítést fejlesztettünk ki annak érdekében, hogy az asztali verzióhoz tervezett nagy űrlapok automatikusan alkalmazkodjanak a mobil eszközök kis képernyőjéhez.

Például azt találtuk, hogy a nagy formák általában kevés fontos elemet tartalmaznak. Vagyis olyan elemek, amelyekkel a munka folyamatban van. És ugyanakkor sok kevésbé fontos elem is van bennük, olyan munka, amellyel időről időre megtörténik a munka.

Például fontos elemek egy dinamikus listatábla lista formájában, egy táblázatos dokumentum jelentés formájában. Fontos oszlopok például a „Név” és a „Dátum” oszlopok.

Ennek megfelelően az űrlappal való munka megfelelő szintű kényelmének biztosítása érdekében a mobil kliens több helyet ad az űrlapon a fontos elemeknek, és kevesebb helyet a kevésbé fontos elemeknek, például egy összecsukható csoportban eltávolítja azokat.

Másodszor, a mobil kliens függőlegesen kibontja a vízszintes csoportokat, ha nem férnek el a képernyő szélességéhez. Mobileszközökön nem szokás és kényelmetlen az űrlapot vízszintesen görgetni, így ez a megoldás meglehetősen kényelmes és indokolt.

A konfigurációk hozzáigazítása a mobil klienshez

Az automatizálás ellenére a konfiguráció fejlesztőjének némi erőfeszítésre lesz szüksége ahhoz, hogy az alkalmazásmegoldást a mobil klienshez igazítsa.

Anélkül, hogy belemennénk a részletekbe, azt mondhatjuk, hogy minden ilyen fejlesztés két fő irányba illeszkedik.

Az első, hogy megszabaduljunk a speciális és specifikus interfész-megoldásoktól, inkább a platform által adattípus-információk alapján végzett automatikus űrlapelrendezésre támaszkodva. Ilyen konkrét megoldások lehetnek a rögzített mezőméretek, az elemek mereven beállított vízszintes csoportosítása és hasonlók.

Egy másik irány az, hogy a mobil klienst további információkkal látjuk el az űrlapelemekről. Megtanítottuk a mobil klienst arra, hogy könnyen felismerje a szabványos vagy kisméretű elemeket és meghatározza azok fontosságát. De ha az űrlap nem szabványos vagy nagy, akkor hasznos lesz manuálisan jelezni, hogy mely elemei fontosabbak és kevésbé fontosak. Ehhez használhatja az új elem tulajdonságot - ImportanceOnDisplay: magas, normál, alacsony stb.

Valószínűleg szükséges lesz elemezni az alkalmazásmegoldás azon helyeit is, ahol a vékonykliens és a webkliens működési algoritmusai eltérnek. Ezt meg kell tenni annak meghatározásához, hogy melyik algoritmus kerül alkalmazásra a mobil kliensben végzett munka során. Ehhez hozzáadtunk egy új, MobileClient fordítási direktívát.

Terjesztés, készítés és közzététel

A mobilkliens valójában egyfajta „héj”, amely képes elindítani egyik vagy másik alkalmazásmegoldást. Ugyanakkor az elindított alkalmazásmegoldások funkcionalitása nagymértékben eltérhet egymástól. Ugyanakkor az AppStore megköveteli, hogy az áruházban közzétett alkalmazás a megjelenést követően ne változtassa meg jelentősen a funkcionalitását.

Ezért a mobilklienst nem tesszük közzé önálló univerzális alkalmazásként. A mobil klienst a mobilplatformmal együtt futtatható fájlok készleteként szállítjuk. Ezen fájlok alapján a fejlesztőnek létre kell hoznia egy mobileszközön futó alkalmazást. Az alkalmazások létrehozásának és közzétételének eljárásai mind a mobilplatform, mind a mobilkliens esetében hasonlóak. Ugyanezt az eszközt használják - a mobil alkalmazások összeszerelőjét.

Ahhoz, hogy az alkalmazásboltban közzétett mobilkliens fix funkciókkal rendelkezzen, meg kell adnia azokat a konkrét konfigurációkat, amelyekkel az alkalmazás működni fog a felépítésekor. Működés közben a mobil kliens ellenőrzi, hogy a megadott konfigurációk közül csak az egyiket használja-e, és nincs-e jelentős változtatás. Ez egy speciális védelem, amely megakadályozza, hogy egy bizonyos konfigurációkhoz közzétett mobil kliens ne működhessen más konfigurációkkal. Amint azt a gyakorlat mutatja, a felhasználók számára kényelmes, ha egy mobilalkalmazás bármely konfigurációnak vagy hasonló konfigurációknak felel meg.