- Kod JavaScript sterujący zachowaniem formularzy jest przechowywany w bazie danych, a nie w plikach aplikacji — dzięki temu zmiana nie wymaga ponownego wdrożenia.
- Blok kodu jest identyfikowany numerem
REFNO, do którego odwołuje się definicja formularza lub kontrolki. - Znaczniki
SYSTEMOWEiKONFIGURACJArozdzielają kod dostarczany z systemem od zmian wprowadzonych na konkretnym wdrożeniu. - Status
ACHpozwala wycofać blok bez usuwania go z bazy, co ułatwia powrót do poprzedniej wersji.
Do czego służy tabela [dbo].[_code_js]
Aplikacje StudioSystem działają w przeglądarce, a zachowanie ich formularzy — walidacja pól, podpowiedzi, reakcja na skanowanie kodu — bywa różne w każdym wdrożeniu. Trzymanie tych reguł w plikach aplikacji oznaczałoby, że każda zmiana wymaga wgrania nowej wersji programu. Tabela [dbo].[_code_js] odwraca ten porządek: bloki kodu leżą w bazie i są pobierane w chwili wyświetlenia formularza.
Praktyczna konsekwencja jest taka, że modyfikacja zachowania ekranu sprowadza się do edycji jednego wiersza. Wdrożeniowiec może dostosować walidację do procesu klienta bez udziału zespołu programistycznego i bez przerwy w pracy systemu.
Ta sama swoboda wymaga jednak dyscypliny. Kod zapisany w bazie nie przechodzi przez kompilację ani przez proces przeglądu, dlatego błąd składniowy ujawni się dopiero u użytkownika. Stąd znaczenie statusu rekordu i znacznika wskazującego, czy blok pochodzi z instalacji standardowej.
Definicja ekranuFormularz wskazuje numer REFNO bloku, którego potrzebuje
PobranieWarstwa aplikacji odczytuje z tabeli aktywny wiersz o tym numerze
WykonanieKod trafia do strony i steruje zachowaniem pól formularza
ZmianaEdycja wiersza działa od następnego otwarcia ekranu, bez wdrożenia
Kod nie jest kompilowany — obowiązuje zasada testowania każdej zmiany na środowisku kopii przed przeniesieniem jej na produkcję.
Budowa tabeli — wykaz kolumn
Tabela ma prostą strukturę: właściwa treść kodu w jednej kolumnie, a wokół niej metryka pozwalająca ustalić pochodzenie, wersję i stan wpisu.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
ACH | varchar(1) tekst do 1 znaków | nie | Status rekordu, 0 bufor, 1 zatwierdozmy, X usunięty |
CODE | varchar(max) tekst bez limitu długości | nie | blok kodu js |
ID_CODE_JS | int liczba całkowita | tak | Identyfikator wiersza tabeli |
KIEDY | datetime data i godzina | nie | Data i czas dodania rekordu do bazy |
KONFIGURACJA | bit wartość logiczna 0/1 | nie | Czy dany rekord jest altualizowany jako ustawienia konfiguracyjne SS |
LOGIN | varchar(50) tekst do 50 znaków | nie | Login osoby dodającej rekord |
REFNO | bigint liczba całkowita 64-bitowa | nie | Identyfikator bloku kodu js |
STAMP | timestamp znacznik wersji wiersza | nie | Identyfikator czasu ostatniego zapisu |
SYSTEMOWE | bit wartość logiczna 0/1 | nie | Czy dany rekordy jest systemowy? |
TYTUL | varchar(100) tekst do 100 znaków | nie | Krótki opis kodu |
Kolumna CODE ma typ varchar(max), więc długość bloku nie jest praktycznie ograniczona. Nie zwalnia to jednak z dzielenia rozbudowanej logiki na mniejsze, opisane tytułem fragmenty.
Indeksy i wydajność zapytań
Indeksowanie jest tu skromne, bo tabela jest odczytywana punktowo — po numerze bloku, nie przeszukiwana zakresami.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__code_js | ID_CODE_JS | klucz główny |
REFNO | REFNO | zwykły |
Indeks na kolumnie REFNO obsługuje podstawowy scenariusz odczytu przy budowaniu ekranu. Klucz główny na ID_CODE_JS zapewnia jednoznaczność wiersza.
Kod w bazie a kod w plikach aplikacji — co z tego wynika
Wybór miejsca przechowywania kodu interfejsu ma konsekwencje, które ujawniają się dopiero po kilku miesiącach eksploatacji. Poniższe zestawienie pokazuje, gdzie każde z podejść pomaga, a gdzie kosztuje.
| Kryterium | Kod w tabeli _code_js | Kod w plikach aplikacji |
|---|---|---|
| Wprowadzenie zmiany | Edycja wiersza, działa od następnego otwarcia ekranu | Wymaga wydania i wdrożenia nowej wersji |
| Różnice między wdrożeniami | Naturalne — każda baza ma własną zawartość | Wymagają rozgałęzień lub przełączników konfiguracyjnych |
| Wykrywanie błędów | Dopiero przy otwarciu ekranu przez użytkownika | Na etapie budowania paczki wdrożeniowej |
| Historia zmian | Kolumny LOGIN i KIEDY oraz wiersze wycofane statusem X | Pełna historia w repozytorium kodu |
| Przenoszenie na produkcję | Skrypt kopiujący wiersze między bazami | Standardowy proces wydawniczy |
Przechowywanie kodu w bazie opłaca się przy zmianach specyficznych dla jednego wdrożenia. Logika wspólna dla wszystkich klientów należy do plików aplikacji.
Praktyczny wniosek jest taki, że obu podejść używa się równolegle. Zachowania standardowe, identyczne u każdego klienta, pozostają w aplikacji i przechodzą przez normalny proces testów. W tabeli lądują wyłącznie odstępstwa wynikające z procesu konkretnej firmy — i właśnie dlatego znacznik SYSTEMOWE ma tu znaczenie porządkujące.
Jak korzystać z tabeli w praktyce
Przy pracy z blokami kodu przechowywanymi w bazie sprawdzają się następujące zasady:
- Wypełniaj kolumnę
TYTULzrozumiałym opisem — po kilku miesiącach to jedyna wskazówka, do czego dany blok służy. - Nie modyfikuj wierszy oznaczonych jako
SYSTEMOWE; zostaną nadpisane przy aktualizacji. Utwórz kopię z własnym numerem i podmień odwołanie w definicji formularza. - Przed zmianą zapisz poprzednią treść — najprościej dodając nowy wiersz i wycofując stary statusem
X, zamiast nadpisywać kolumnęCODE. - Testuj każdą zmianę na kopii bazy. Błąd składniowy w JavaScripcie nie zostanie wykryty przy zapisie do tabeli, tylko przy otwarciu ekranu przez użytkownika.
- Kolumny
LOGINiKIEDYpozwalają ustalić autora i datę zmiany — warto z nich korzystać przy ustalaniu przyczyny nagłej zmiany zachowania ekranu. - Nie umieszczaj w kodzie danych dostępowych ani adresów usług; te należą do tabeli parametrów konfiguracyjnych.
Zapytanie zestawiające aktywne bloki kodu wraz z datą ostatniej modyfikacji i informacją o pochodzeniu:
SELECT REFNO,
TYTUL,
LOGIN,
KIEDY,
CASE SYSTEMOWE WHEN 1 THEN 'standardowy'
ELSE 'wdrożeniowy' END AS POCHODZENIE,
LEN(CODE) AS DLUGOSC
FROM dbo._code_js
WHERE ISNULL(ACH, '1') <> 'X'
ORDER BY KIEDY DESC;Warunek ISNULL(ACH, '1') jest tu potrzebny, bo kolumna statusu dopuszcza wartość pustą — wiersze bez ustawionego statusu traktujemy jako aktywne.
Bloki kodu w bazie danych to rozwiązanie wygodne we wdrożeniu i kłopotliwe w utrzymaniu, jeżeli nikt nie pilnuje porządku. Regularny przegląd wierszy nieużywanych od dłuższego czasu oszczędza sporo pracy przy późniejszej migracji.
Powiązane tabele i dokumentacja
Bloki kodu współpracują z definicjami zapytań i ekranów opisanymi w pozostałych tabelach konfiguracyjnych: