Arayüz Oluşturma Motoru
TotalApp'te onay ekranlarının ve diğer motorların ürettiği formların arkasındaki Sunucu Güdümlü Arayüz (Server-Driven UI) katmanı. Diğer bir motorun ihtiyaç duyduğu her tablo veya form kombinasyonu için ayrı bir ekran elle kodlamak yerine, bu motor ekranı küçük bir JSON ağacı olarak tanımlar; frontend bunu paylaşılan, tema duyarlı bir bileşen kataloğuyla anında render eder.
Arayüz Oluşturma Motoru Nedir?
Matris Ajanı bir tedarikçiyi, bir lead'i veya bir uyumluluk kaydını puanlamayı bitirdiğinde, çoğu zaman sonucun kesinleşmesinden önce bir insanın bunu gözden geçirmesi gerekir — bir satın alma siparişini onaylamak, bir lead'in satışa devredilmeye hazır olduğunu doğrulamak, bir uyumluluk bulgusunu imzalamak. Bu anların her biri küçük, odaklı bir ekrana ihtiyaç duyar: birkaç salt okunur alan, bir durum rozeti, tek bir onay düğmesi. Bu anların her biri için, ihtiyaç duyabilecek her modül genelinde özel bir frontend sayfası elle inşa etmek, neredeyse birbirinin aynısı düzinelerce ekranı elle yazmak (ve sürdürmek) anlamına gelirdi.
Arayüz Oluşturma Motoru bunu bir Sunucu Güdümlü Arayüz (Server-Driven UI) yaklaşımıyla çözer: bir frontend geliştiricisinin her ekran için yeni bir sayfa yazması yerine, backend ekranı bir JSON bileşen ağacı olarak tanımlar — bir input, bir rozet, bir düğme içeren bir form — ve bu tanımı frontend'e devreder. Frontend bu ağacı bir kez okur ve her iki tarafta da sayfaya özgü bir kod değişikliği olmadan onu anında çalışan, tamamen biçimlendirilmiş bir ekrana dönüştürür.
Stil hiçbir zaman bu JSON ağacının içinde seyahat etmez. Her bileşen yalnızca semantik bir rol taşır — primary, success, danger — ve frontend'deki paylaşılan, tema duyarlı bir katalog bu rolü render anında gerçek renklere ve boşluklara dönüştürür. Her kiracının marka renklerinin, motorun bu renkleri hiç bilmesine gerek kalmadan otomatik olarak uygulanmasını sağlayan şey tam olarak budur.
Tek cümlede
Diğer motorlar bir ekranı veri olarak tanımlar — inputlar, bir rozet, bir düğme — ve bu motor bu tanımı frontend'e devreder; frontend de bunu, kimse özel bir sayfa yazmadan çalışan, markaya uygun bir ekrana dönüştürür.
Nasıl Çalışır — Elle Kodlamak Yerine Tanımlamak
Bu motorun ürettiği her ekran, "gözden geçirilmesi gereken bir şey var"dan "kullanıcının cihazında çalışan bir ekran"a kadar aynı üç aşamalı yoldan geçer:
| Aşama | Ne olur |
|---|---|
| 1. Şemayı Oluştur | Motor, gözden geçirilmesi gereken kaydı — bir sipariş, puanlanmış bir tedarikçi, işaretlenmiş bir uyumluluk öğesi — alır ve ekranı tanımlayan küçük bir bileşen ağacı oluşturur: bir durum rozeti, kaydın temel ayrıntılarını gösteren bir veya iki salt okunur alan ve bir onay düğmesi içeren bir form. |
| 2. JSON Olarak Gönder | Bu bileşen ağacı düz JSON olarak döndürülür — HTML yok, stil yok, kiracıya özel renk yok. Her bileşen yalnızca ne olduğunu (bir input, bir düğme) ve hangi rolü oynadığını (birincil bir eylem, başarı rozeti) adlandırır. |
| 3. Cihazda Render Et | Frontend'in renderer'ı ağacı dolaşır ve her bileşen için, render edilecek gerçek sınıfları çözmek üzere semantik rolünü paylaşılan bir stil kataloğunda arar. Bir kiracının kendi marka renkleri otomatik olarak uygulanır, çünkü renkler şemada değil katalogda yaşar. |
Stil neden tamamen şemanın dışında tutuluyor?
Backend gerçek renkleri veya Tailwind sınıflarını doğrudan gömseydi, farklı bir marka paletine sahip her kiracının kendi şema oluşturma mantığı kopyasına ihtiyacı olurdu — ve her gelecek tema, her motordaki her ekran üretme kod yoluna dokunmak anlamına gelirdi. Yalnızca semantik bir rol adlandırarak, aynı şema her kiracı ve her tema için doğru render edilir; yalnızca frontend'in kataloğunun "primary" veya "success"in gerçekte neye benzediğini bilmesi gerekir.
Girdi — Bir Ekran İsteğinin Taşıdıkları
Bir onay ekranı oluşturmak için motorun yalnızca kaydın kendi temel gerçeklerine ihtiyacı vardır — ekranın nasıl görüneceğine dair hiçbir şeye değil:
Kayıt Kimliği
Bu ekranın hakkında olduğu sipariş numarası, tedarikçi kimliği veya kayıt referansı — gözden geçirene tam olarak neyi onayladığını bilmesi için salt okunur bir alan olarak gösterilir.
Anahtar Değer
Kayda bağlı en önemli tek sayı — bir toplam fiyat, bir puan, bir vadesi geçmiş tutar — gözden geçirenin başka bir yerde aramasına gerek kalmaması için öne çıkarılır.
Yapay Zeka Doğrulama İşareti
Yukarı akış bir motorun (tipik olarak Matrix Agent) bu kaydı zaten otomatik olarak doğrulayıp doğrulamadığı — gözden geçirenin işin ne kadarının zaten tamamlandığını bilmesi için bir durum rozeti olarak gösterilir.
Asla gönderilmez: renkler, boşluklar veya düzen
Bir ekran oluşturma isteği hiçbir zaman herhangi bir tür stil bilgisi içermez. Bir kiracının marka renkleri değişirse veya bir bileşenin varsayılan stili uygulama genelinde değişirse, hiçbir yerdeki hiçbir istek yükünün değişmesi gerekmez — yalnızca frontend'in paylaşılan stil kataloğu değişir.
Çıktı — Render Edilmeye Hazır Bir Bileşen Ağacı
Motorun yanıtı, her biri birkaç desteklenen bileşen türünden biri olan, tipli düğümlerden oluşan küçük bir ağaçtır:
| Bileşen | Neyi temsil eder |
|---|---|
| Form | Bir ekranın dış kapsayıcısı — bu belirli incelemeye ait her diğer bileşeni tutar. |
| Input | Tek, etiketli bir alan; gözden geçiren ham veriyi düzenlemek yerine bir kararı onayladığından tipik olarak salt okunur gösterilir. |
| Badge | Küçük bir durum hapı — örneğin, kaydın yukarı akış bir yapay zeka adımı tarafından zaten doğrulanıp doğrulanmadığını gösterir. |
| Button | Gözden geçirenin ekranı bitirmek için yaptığı eylem — neredeyse her zaman ekran başına tek bir onay düğmesi. |
| Table | Birkaç tekil alan yerine ilişkili satırların bir listesini göstermesi gereken ekranlar için ayrılmış bir bileşen türü. |
Her bileşen bir literal renk değil, her zaman semantik bir varyant taşır
Bir Button veya Badge yalnızca primary, success veya danger gibi bir rol bildirir. Frontend'in paylaşılan stil kataloğu, bu rollerin her birinin geçerli kiracı ve tema için gerçekte neye benzediğine karar veren tek yerdir.
Son Kullanıcılar Bunu Nasıl Kullanıyor?
Yapay Zeka ile Puanlanmış Bir Kaydı Onaylama
Matrix Agent bir tedarikçiyi veya lead'i puanlamayı bitirdiğinde ve bu kesinleşmeden önce bir insanın imzalaması gerektiğinde, gözden geçiren küçük, odaklı bir ekran görür — kaydın temel ayrıntıları, zaten yapay zeka tarafından doğrulandığını gösteren bir rozet ve onaylamak için tek bir düğme. Yapılandırılacak hiçbir şey ve öğrenilmesi gereken ekstra bir şey yoktur; ekran tam olarak o tek karar için inşa edilmiştir.
Yeni Bir Onay Adımını Hızla Yayına Almak
Yeni bir modülün kendi "lütfen bunu onaylayın" anına ihtiyacı olduğunda, tasarlanıp inşa edilecek yeni bir frontend sayfası beklemez — bu motordan göstermesi gereken alanları tanımlayan bir şema ister ve bu istek bağlandığı anda çalışan, markaya uygun bir ekran var olur.
Arayüz Oluşturma Motoru Nereye Uyuyor?
Bu motor kendi başına puanlama, denetim veya işleme yapmaz — başka bir motorun tamamlanmış sonucunu bir insanın harekete geçebileceği bir ekrana dönüştürür:
| Kaynak Motor | Ne render ediliyor |
|---|---|
| Matris Ajanı | Onaylanmış sayılmadan önce bir insanın nihai onayına ihtiyaç duyan, puanlanmış bir tedarikçi, lead veya uyumluluk kaydı. |
| Entegrasyon & Webhook Motoru | İleri gönderilmeden önce (örneğin bir ERP sistemine) hızlı bir insan incelemesine ihtiyaç duyan, harici bir platformdan gelen bir sipariş veya kayıt. |
| Denetim Ajanı | Bir gözden geçirenin onaylamasını veya reddetmesini gerektiren, bir belge incelemesinden işaretlenmiş bir bulgu. |
Olay & Analitik Motoru gibi, bu motorun oluşturduğu her ekran da kendi üretimini sessizce izlenen bir olay olarak rapor eder — böylece oluşturulamayan bir şema, TotalApp'teki her şeyle aynı kullanım ve sağlık geçmişinde görünür.
Ayarladığınız bir ekran değil, diğer motorların çağırdığı paylaşılan bir katman
Bu motorun kendi özel ayar ekranı yoktur — diğer motorlar bir onay adımına ihtiyaç duyduklarında onu çağırır ve ortaya çıkan ekran hemen görünür. Açılacak hiçbir şey yoktur; bir motor ondan bir şema istemek üzere bağlanmışsa, o ekran zaten kullanılabilirdir.