Integrace umělé inteligence
CENTRALIZACE POSKYTOVATELŮ A MODELŮ UMĚLÉ INTELIGENCE S POUŽITELNÝMI ALIASY
Poskytovatelé a modely AI jsou nyní definováni na speciální záložce AI v nastavení a lze je znovu použít v celé aplikaci.
Každý poskytovatel ukládá svou základní URL, klíč API a volitelné identifikátory. Připojení lze otestovat přímo, takže přístup je ověřen před provedením jakéhokoli volání. Po konfiguraci se poskytovatelé stanou součástí nastavení projektu a řídí se stejnou logikou nasazení napříč konfiguracemi na úrovni struktury, uživatele nebo dat.
Používání modelů je zjednodušeno dvěma přístupy. Na modely můžete odkazovat pomocí formátu založeného na poskytovateli, jako je ProviderName:ModelName, nebo definovat aliasy modelů, které mapují vlastní název na poskytovatele a ID modelu. Když se atribut model shoduje s aliasem, 4D automaticky vyřeší konfiguraci přidruženého poskytovatele a modelu.
Díky tomu není nutné opakovat podrobnosti o poskytovateli nebo identifikátory modelů v celém kódu. Přepínání poskytovatelů, aktualizace přihlašovacích údajů nebo nahrazování modelů nevyžaduje změny ve více metodách.
Konfigurace poskytovatelů a modelů zůstávají během běhu přístupné prostřednictvím třídy OpenAIProviders. Můžete zkontrolovat dostupné poskytovatele, načíst aliasy modelů nebo v případě potřeby dynamicky přizpůsobit chování.
Integrace AI se s rostoucím rozsahem stává snáze spravovatelnou. Konfigurace zůstává centralizovaná, použití modelů konzistentní a váš kód se soustředí na logiku aplikace namísto externího nastavení.
Uživatelské rozhraní
VZHLED LIQUID GLASS PRO FORMULÁŘE 4D NA macOS
Ve verzi 4D 21 R3 formuláře v systému macOS automaticky přejímají systémový styl Liquid Glass.
Standardní objekty, jako jsou tlačítka, seznamy a nabídky, se řídí aktualizovanými rozestupy, průhledností a vizuální zpětnou vazbou definovanými systémem macOS. Změny se projeví vizuálně, zatímco logika formulářů a zpracování událostí zůstávají beze změny.
Vzhledem k tomu, že tento styl zavádí průhlednost a zaoblené tvary, může být u rozvržení s malými mezerami nebo vrstvenými prvky nutné provést drobné úpravy.
Aplikace se přizpůsobují aktuálním konvencím macOS, aniž by se měnil způsob vytváření formulářů.
VYTVÁŘEJTE MODERNÍ ROZHRANÍ S FLUENT UI A LIQUID GLASS
Ve verzi 4D 21 R3 podporuje knihovna objektů Fluent UI ve Windows a Liquid Glass v macOS.
Stávající komponenty se vykreslují pomocí vybraného designového systému, aniž by se změnila jejich definice. Stejné formuláře se přizpůsobují napříč platformami a zachovávají konzistentní a moderní rozhraní bez nutnosti redesignu.
Aktualizované komponenty odpovídají současným vývojovým postupům a při přidání nebo regeneraci mají přehlednější objektové metody.
Rozhraní se vyvíjí napříč platformami, zatímco struktura a logika zůstávají nezměněny.
TISK MODERNÍCH FORMULÁŘŮ S VYTVÁŘENÍM OPTIMALIZOVANÝM PRO PAPÍR
Ve verzi 4D 21 R3 jsou formuláře využívající moderní styly uživatelského rozhraní automaticky přizpůsobeny pro tisk.
Widgety jsou převedeny na ploché, monochromatické zobrazení a vizuální efekty, jako je průhlednost a stíny, jsou odstraněny. Rozložení, zarovnání a rozměry zůstávají zachovány a vytištěné hodnoty odpovídají aktuálnímu stavu, včetně neuložených dat.
Transformace probíhá automaticky a vytváří konzistentní výstup v systémech macOS i Windows, aniž by došlo ke změnám v logice tisku.
SÍŤ
ODSTRANĚNÍ STARÉ SÍTĚ
Ve verzi 4D 21 R3 byla odstraněna síťová vrstva Legacy.
Nové projekty používají ve výchozím nastavení QUIC, zatímco binární databáze používají ServerNet. Síťová vrstva se definuje při vytvoření na základě typu aplikace.
Stávající aplikace, které stále odkazují na Legacy, zůstávají kompatibilní. Při běhu používá 4D ServerNet, takže aplikace pokračují v běhu na podporované vrstvě, aniž by vyžadovaly okamžité změny.
Podporované protokoly se stávají standardem, zatímco Legacy již není součástí konfigurace.
PŘIJÍMEJTE UDÁLOSTI E-MAILŮ V REÁLNÉM ČASE S IMAP IDLE
Ve verzi 4D 21 R3 podporuje IMAPTransporter protokol IDLE, což aplikacím umožňuje reagovat na změny v poštovní schránce v okamžiku, kdy k nim dojde.
Příkaz IMAP New transporter nyní přijímá objekt listener, ve kterém lze definovat zpětné volání pro události jako onMailCreated, onMailDeleted a onFlagsModified. Každé zpětné volání přijímá transporter a objekt události s podrobnostmi, jako je počet zpráv, pořadové číslo nebo aktualizované příznaky.
Oznámení se řídí prostřednictvím vlastnosti notifier. Volání notifier.start() se přihlásí k odběru událostí serveru, zatímco notifier.stop() je pozastaví. Je-li aktivní, transportér udržuje živé připojení a doručuje události, místo aby se spoléhal na periodické dotazování.
Tím se zpracování e-mailů přesouvá z plánovaných kontrol na tok řízený událostmi. Aplikace zůstávají v souladu se stavem poštovní schránky, omezují zbytečné požadavky a mohou aktualizovat uživatelské rozhraní nebo spustit logiku, jakmile dojde ke změnám.
4D Write Pro
STRUKTUROVÁNÍ DOKUMENTŮ S HIERARCHICKÝMI ČÍSLOVANÝMI SEZNAMY
Ve verzi 4D 21 R3 se číslované seznamy v 4D Write Pro posouvají od jednoduchého formátování ke strukturované organizaci dokumentů. Nyní můžete definovat hierarchické číslování napříč několika úrovněmi, což umožňuje automaticky zachovat konzistenci sekcí, podsekcí a vnořeného obsahu.
Číslování se definuje prostřednictvím propojených stylů odstavců, kde každá úroveň následuje strukturovanou hierarchii. Formáty jako 1, 1.1 a 1.1.1 se generují automaticky.
Při přidávání, odstraňování nebo reorganizaci obsahu se číslování aktualizuje na všech úrovních bez nutnosti ruční úpravy.
Díky tomuto přístupu již není nutné číslování restartovat ani udržovat pomocí kódu. Číslování místo toho sleduje strukturu, kterou definujete, a zajišťuje tak konzistenci v dlouhých nebo složitých dokumentech.
Jazyk 4D
Přístup k uživatelským relacím přímo z 4D CLIENT
Ve verzi 4D 21 R3 byl příkaz Session rozšířen na 4D Client a nyní vrací objekt vzdálené relace namísto Null.
Data relace, jako je ID relace, uživatelské jméno a kontext, jsou přímo přístupná z 4D klienta. Funkce jako createOTP(), getPrivileges(), hasPrivilege() a isGuest()lze volat lokálně, přičemž stále odrážejí relaci na serveru.
Tím odpadá nutnost přeskupovat kód jen kvůli přístupu k informacím o relaci. Logika může zůstat tam, kde se používá, což usnadňuje sledování toků a snižuje počet mezilehlých metod potřebných v klient-serverových aplikacích.
Hybridní scénáře se také stávají přímějšími. Klient může vygenerovat OTP a otevřít stránku Qodly ve stejném ověřeném kontextu bez další koordinace.
Omezení na straně serveru zůstávají nezměněna. Funkce pro úpravu oprávnění se stále provádějí pouze na serveru a úložiště klienta zůstává oddělené.
Zpracování relace se stává snáze integrovatelným do stávajícího kódu, aniž by bylo nutné jej restrukturalizovat kolem kontextu provádění.
SPOUŠTĚNÍ FUNKCÍ SHARED A SESSION SINGLETON NA SERVERU
Ve verzi 4D 21 R3 podporují funkce sdílených a relací singletonů klíčové slovo ` server `, což jim umožňuje spouštět se na serveru, i když jsou volány z klienta 4D.
Funkce běží na serverové instanci singletonu. Pokud žádná instance neexistuje, je automaticky vytvořena, což znamená, že singleton může existovat jak na klientovi, tak na serveru s odlišnými hodnotami vlastností.
To platí pro třídy sdílených a relačních singletonů. Klíčové slovo ` local ` lze i nadále používat pro větší přehlednost, zatímco funkce datového modelu ORDA přijímají pro větší jednoznačnost také ` server `.
Parametry a vrácené hodnoty musí být streamovatelné a musí se řídit stejným modelem provádění jako funkce ORDA na straně serveru.
Logika související se relací, operace se sdílenou pamětí a zpracování závislé na serveru nyní mohou zůstat uvnitř singletonu, který je definuje, aniž by byly přesunuty do metod projektu nebo funkcí ORDA za účelem řízení místa provedení.
Proměňte dynamický text na skutečné spustitelné metody
Ve verzi 4D 21 R3 umožňuje nová třída 4D.Method spouštět kód uložený jako text jako nativní metodu.
Metoda je vytvořena pomocí 4D.Method.new() a chová se jako nativní metoda. Lze ji spustit, uložit do objektů nebo vyvolat pomocí call() a apply(). Parametry jsou předávány strukturovaným způsobem a This vrací hostitelský objekt během provádění.
Před spuštěním checkSyntax() ověří zdrojový kód a vrátí podrobné informace o chybách a varováních, včetně čísel řádků.
To umožňuje zavést dynamickou logiku bez ztráty kontroly. Kód uložený v databázích nebo externích zdrojích lze ověřit a spustit pomocí stejného jazykového modelu, což zvyšuje spolehlivost přizpůsobení běhu a usnadňuje údržbu.
Spouštění zůstává konzistentní napříč prostředími, protože metody běží v interpretovaném režimu i v kompilovaných aplikacích.
Dynamické chování se integruje do aplikace, místo aby zůstávalo izolovaným mechanismem.
OVĚŘENÍ JSON S MODERNÍMI STANDARDY SCHEMAT
Ve verzi 4D 21 R3 nyní příkaz „ JSON Validate “ podporuje nejnovější standard JSON Schema (návrh 2020-12).
Schémata nyní mohou zahrnovat podmíněnou logiku, pokročilá omezení a rozšířenou validaci formátu. To umožňuje vyjádřit více validačních pravidel přímo ve schématu namísto jejich implementace v kódu.
Díky tomu lze logiku ověřování sdílet napříč systémy bez duplicit. Backend, frontend a externí služby se mohou opírat o stejné schéma, což zajišťuje jednotné chování při toku dat mezi nimi.
Hlášení chyb je přesnější, což usnadňuje identifikaci a opravu problémů s validací. Stávající schémata Draft-04 zůstávají podporována a validační engine se vybírá automaticky na základě atributu $schema.
KONSISTENTNÍ OVĚŘOVÁNÍ DATUMŮ V SCHÉMATECH JSON
Ve verzi 4D 21 R3 zpracovává JSON Validate data konzistentně, ať už jsou uložena jako řetězce nebo jako nativní hodnoty 4D Date.
Validace se řídí definicí schématu bez ohledu na to, jak je datum interně reprezentováno. Tím se odstraní nesrovnalosti při toku dat mezi JSON, API a interním zpracováním.
Schémata zůstávají referencí pro pravidla ověřování, aniž by před ověřením vyžadovala dodatečnou logiku převodu.
CHYBY PARAMETRŮ PŘÍKAZŮ CATCH V EDITORU
Ve verzi 4D 21 R3 je kontrola syntaxe rozšířena tak, aby ověřovala parametry příkazů přímo v editoru pomocí typů a syntaktických vzorů definovaných v dokumentaci.
Pokud příkaz očekává konkrétní typ, jako je Text, Integer, Object, Pointer nebo přiřaditelná proměnná, jsou nyní neplatné argumenty detekovány již při psaní kódu, namísto toho, aby se objevily později při běhu nebo během kontroly syntaxe. To platí také pro zdokumentované parametry více typů, variadické parametry a skupiny variadických parametrů.
Kontroly jsou nyní přesnější v běžných případech, jako jsou nesprávné typy argumentů, předání nepřidělitelných hodnot tam, kde je vyžadována proměnná, nebo podpisy příkazů, které závisí na konkrétní dokumentované syntaxi. Stávající kontrola syntaxe příkazů zde není nahrazena. Je rozšířena tak, aby pokrývala širší a přesnější sadu pravidel pro parametry jak v editoru kódu 4D, tak ve VS Code.
Díky tomu se použití příkazů více přibližuje tomu, co dokumentace skutečně definuje, takže neplatná volání jsou identifikována dříve a opravena dříve, než se dále rozšíří do vývojového cyklu.
Komponenta 4D
SPRÁVA ZÁVISLOSTÍ KOMPONENT GITLAB Z ROZHRANÍ PROJEKTU
Ve verzi 4D 21 R3 rozhraní Project Dependencies nyní podporuje repozitáře GitLab, čímž rozšiřuje stávající správu závislostí nad rámec GitHubu.
Komponenty lze přidávat přímo z repozitáře GitLab pomocí úplné URL adresy nebo cesty k repozitáři. Soukromé repozitáře jsou podporovány prostřednictvím osobních přístupových tokenů, které lze definovat pro každý server a znovu použít napříč závislostmi.
Výběr verze se řídí stejnou logikou jako u ostatních komponent. Závislosti mohou cílit na nejvyšší dostupnou verzi, konkrétní značku nebo sémantickou verzi, což umožňuje přesnou kontrolu nad tím, co je do projektu integrováno.
Po přidání se komponenty GitLab chovají jako jakákoli jiná závislost. Jsou uvedeny v rozhraní Project Dependencies, nainstalovány při restartu projektu a lze je aktualizovat, kontrolovat nebo odstranit, aniž by bylo nutné opustit prostředí.
Správa závislostí se stává konzistentní napříč zdroji repozitářů, takže komponenty hostované na GitLabu se řídí stejnými pravidly životního cyklu a verzování jako zbytek projektu.
Rozšíření pro Visual Studio Code
VIZUÁLNÍ ÚPRAVA ROLÍ, OPRÁVNĚNÍ A HTTP HANDLERŮ V VS CODE
Strukturované projektové soubory lze nyní upravovat pomocí specializovaných editorů uživatelského rozhraní přímo ve VS Code.
Role a oprávnění, stejně jako HTTP handlery, se otevírají ve vizuálním rozhraní namísto surového JSON. Pole jsou uspořádaná, možnosti jsou explicitní a konfigurace lze aktualizovat bez nutnosti procházet vnořené struktury nebo ručně spravovat syntaxi.
Ověřování je integrováno. Je obtížnější zadat neplatné konfigurace a běžným chybám způsobeným formátováním nebo strukturou se lze vyhnout ještě před spuštěním.
Stejné soubory zůstávají kdykoli přístupné jako text. Můžete přepínat mezi úpravami v surovém formátu a uživatelským rozhraním v závislosti na úkolu, aniž byste museli měnit svůj pracovní postup nebo nástroje.
Díky tomu je konfigurace snáze čitelná, bezpečněji upravitelná a přístupnější pro celý tým, přičemž zůstává plně integrovaná do vašeho prostředí VS Code.
ZÁVISLOSTI NYNÍ PLNĚ ROZPOZNÁVÁNY V VS CODE
Ve verzi 4D 21 R3 načítá rozšíření 4D-Analyzer závislosti projektu stejným způsobem jako 4D. Díky automatickému vyřešení závislostí se kontrola syntaxe a doplňování kódu opírají o stejný kontext jako 4D IDE, takže zpětná vazba zůstává konzistentní napříč prostředími.
Rozšíření čte závislosti jak ze souboru dependencies.json, tak z environment4d.json. Komponenty sdílené mezi více projekty jsou detekovány bez další konfigurace a aktualizace těchto souborů spouští automatické znovu načtení projektu, takže se změny okamžitě projeví v editoru.
Integrace GitHubu se řídí stejnou logikou jako 4D. Komponenty se stahují pomocí stejného lokálního úložiště, čímž se zabrání duplikaci a zajistí se synchronizace verzí. Pokud je v VS Code již aktivní relace GitHubu, je automaticky znovu použita. Pokud ne, lze relaci otevřít přímo z rozšíření a získat přístup k veřejným i soukromým repozitářům bez přerušení pracovního postupu.
VS Code přestává hádat. Pracuje se stejnými závislostmi, stejnou strukturou a stejnými pravidly jako vaše aplikace 4D
zabezpečení
POUŽÍVEJTE CERTIFIKÁTY MACOS KEYCHAIN PŘÍMO V HTTPS POŽADAVCÍCH
Ve verzi 4D 21 R3 mohou HTTPS požadavky a HTTP agenti používat certifikáty uložené přímo v klíčenku macOS.
Při vytváření objektu typu „ HTTPRequest “ nebo „ HTTPAgent “ se na certifikáty odkazuje podle názvu pomocí vlastnosti „ storeCertificateName “. 4D vyhledá certifikát prostřednictvím operačního systému a pokud certifikát nenajde, okamžitě vrátí chybu.
Tento přístup je stejný jako ten, který je již k dispozici pro úložiště certifikátů Windows, což umožňuje, aby stejný kód fungoval napříč platformami.
Certifikáty již není nutné distribuovat ani ukládat jako soubory v aplikačním prostředí. Nadále je spravuje systém, což zjednodušuje nasazení a zajišťuje konzistentní nakládání s přihlašovacími údaji na všech počítačích.