Jeste tad - kad si mi objašnjav’o mehaniku kretanja i Prvi Newton-ov zakon.
Heh, iz prve.
Propuštam li nešto?
Negdje tu imamo sintaksu za dubinsku provjeru strukture objekta. Znači koliko god multidimension strukturu objekta?
Više manje svaki jezik ima jednostavan način da se provjeri jel nešto integer ili array ili string…
Ali ako tvoj post nije bio ironično i plitko poklapanje gornjoj ideji…onda se slažem da tu zaista ima zgodnih stvarčica koje se mogu uzeti u obzir da se moja gornja pravila dodatno obogate. 
Može neki konkretni primjer iz prakse za tvoje strukture?
Ili da malo drukčije postavim pitanje, gdje bi bila primjena ovog i za što konkretno?
Nemam ovdje nego na poslu…ali u suštini radim jedan API servis i pokazala se potreba da se automatizira validacija objekta kojeg prima API.
A kako sam već prije razvijao ovu sintaksu, pokazala se odličnom upravo i za gornju primjenu.
Može se to naravno pisati code koji isprovjerava stanja objekta i javi povratno ako ima nešto što nebi smio…ali puno elegantije je to one-line rješiti sa ovom sintaksom. I lako je re-useabilno za druge projekte.
Nadalje, ti si radio sa C# pa znaš da ovisno o ulaznim parametrima se trigira ona funkcija kojoj se tipovi ulaznih parametara poklapaju sa pozivom.
E sad, u jeziku koji to nema, možeš sa ovom sintaksom na glavnom ulazu funkcije napraviti switch sa ovom sintaksom , te ovisno o tipovima ulaznih parametara dalje usmjeriti code u kojem smjeru će se izvršavati.
To je naravno jednostavno ručno napraviti ako su jednodimenzionalni ulazni parametri. Ali ako imaš na ulazu multidimenzionalne parametre…puno toga se olakaša ako imaš one-line code sa kojim ih možeš testirati i ovisno o tome dalje ih procesuirati…
(Inicijalno sam je radi toga krenuo razvijati…ali svjestan sam da će trebati i za normJS da se te validacije multidimenzional objekata mogu standarizirati.)
Od kuda dolaze podaci koje predaješ API servisu?
Sa forme, baze?
Ako sa forme, neki frameworci imaju ugrađenu validaciju za polja, ako dolaze iz baze, onda su podaci određenog tipa, ako ti treba iz baze neki drugi tip , imaš Business logiku gdje to odradiš i pripremiš tip kakav ti treba i napraviš provjeru. Isto tako ako podaci dolaze sa forme, također možeš odraditi sve u Business logici.
Ako se API servisu predaje json type, svaki element prije validiraš ili kao što sam gore napisao za podatke sa forme ili iz baze.
Sintaksa je preglednija, nego da je sve u jednom redu.
Isto tako možeš imati neograničen broj kombinacija, što uključuje različiti broj elemenata, dužina itd…
Ja ne predajem podatke APIu, nego sam ja API koji ih prima. A oni koji šalju ne znaju pročitati dokumentaciju i poslati ispravan parametar.
Težio sam načinu da im što elegantije složim error response, bez da moram puno toga kodirat da isprovjeravam primljeni parametar.
Logično je bilo nekako napraviti univerzalnu validaciju, jer onda sam jednim udarcem rješio više muha…taj isti problem za svaki iduću API servis.
Složiš si za svaki api npr. konfiguraciju sa tipom podatka, dužinom za svaki element i prema tome validiraš i za svaki element error, ako funkcija kod validacije dođe na neki error, odma šalje prvi error sa porukom ili može pokupiti sve error poruke i poslati.
I koliko god da imaš parametara i kakvih god, radiš prema konfiguraciji.
I onda samo pišeš konfiguracije, a sve ostalo ti odrađuje jedna mala funkcija za bilo koji api, za bilo koju konfiguraciju.
A što je gornja sintaksa nego sintaksa koja opisuje konfiguraciju, ili ti ga strukturu?
Kako ti misliš da je najelegantnije složit konfiguraciju?
Ako sam dobro shvatio, ti bi složio jedan ispravan set podataka, pa onaj na ulazu usporedio sa tim ispravnim? Ili kako si zamislio složiti konfiguraciju?
Ako bi mi nesto tako trebalo , slozio bi u xml-u schemu.
Tako funkcionira ubl schema za provjeru ispravnosti el. dokumenata npr. e-racun, ponude i ostalo . Ucitas e-racun npr. u xml-u, ucitas ubl xml scheme i on provjeri sve. Od naziva polja, tip polja, duzina, da li je obavezan ili ne.
Npr. dodas novi parametar u api, moras rijesiti code, ali u xml dodajes 1-3 linije , ovisi kako imas rijeseno, a funkciju za validaciju ne diras ili je odrzavas i prosirujes prema potrebi.
I ti bi kod svakog api- imao validaciju i neku funkciju, dok bi ja dohvatio porametre, pozvao funkciju koja mi pakira podatke u xml schemu, u drugoj funkciji bi ucitao konfiguraciju, validirao podatke i vratio rezultat validacije.
I opet si došao do nekakve sintakse po kojoj ćeš validirati objekt.
Imaš li konkretno pravila sintakse u glavi ili?
XML je tu čak dobar, za razliku od JSONa, on jeste zamišljen da je lako čitljiv od računala i čovjeka.
Samo je on meni ponekad overload sa svim svojim tagovima, ako se pisanje nečeg može pojednostavit.
Al mogo bi čak gornjoj sintaksi dodati alias koji bi se pisao kao xml, pa da piše kako kome paše za konkretnu situaciju.
Kompleksnije nested strukture bi dakako bile preglednije u xml.u
Samo sto imas jednu funkciju za validaciju koja radi sa multi dimenzionalnim poljima i sa bilo kojoj konfiguracijom i moze u dubinu koliko hoces, do limita.
Funkcija koja radi sa gore opisanom sintaksom je jednosmjerna. Možeš sa sintaksom validirat objekt, ali ne možeš iz objekta kreirat sintaksu.
Npr sintaksa “string|int” će validirat 5 kao true. Ali iz broja 5 ne možeš po ničem zaključit da je to string ili integer, kad je on integer.
Nadalje…iz teksta “auto” možeš znati da je to string. Ali ne možeš znati dali je to “username” string. Auto se može uklapat kao username, ali to ne znači da i svaki drugi primjer stringa sa te pozicije spada pod username. Tako da je to neodređeno stanje.
Dok recimo testiraš string sa tipom “username” …onda je stvar određena. Točno znaš jel string koji testiraš zadovoljava ili nezadovoljava username legal chars.
Pa i kod mene je jedna funkcija…ne kuzim poantu poruke.
Tebi dolazi post data, svaki parametar ima svoje ime.
U xml-u navedes ime parametra, type(moze min, max), duzina , error itd…
I ako moras validirati password, a ti imas zapis u xml-u password sa min duzinom 10 i max. duzinom 30, tipom, bilo gdje da ti dodje password, sa duzinom izmedju 10 i 30 znakova , odredjenog tipa, validacija ce proci. Tu treba paziti, ako radis sa drugim pismima.
S time da npr. password moze imati razlicite konfiguracije, tj. svako polje. Mozes imati main konfiguraciju i jos za svaki api, prvo gledas za api, ako nema onda gledas main konfiguraciju.
Kužim što pričaš, imam to rješeno pošto postoji mogućnost registracije custom single typeova.
Recimo, bez registracije custom typova da moramo validirati objekt koji je garaža…koji je array auta, to bi bilo:
//valiator za garažu:
"array<object[brojVrata:int, vozac:objekt, volan:string[left|right]]>"
//Znači samo auto nam je:
"object[brojVrata:int, vozac:objekt, volan:string[left|right]]"
//I sada ako imamo objekt koji ima više garaža morali bi pisati:
"object[
garaza1:array<object[brojVrata:int, vozac:objekt, volan:string[left|right]]>
garaza2:array<object[brojVrata:int, vozac:objekt, volan:string[left|right]]>
]"
//što je glupo, jer želimo pisati:
"object[
garaza1:array<auto>
garaza2:array<auto>
]"
//ili još bolje, želimo pisati:
"object[
garaza1:garaza,
garaza2:garaza
]"
// Pa se to postiže vrlo jednostavno i po već poznatom principu deklaracija klasa. Tako da sintaksa koja će istovremeno deklarirati klasu i koristiti je za validaciju izgleda:
"
@auto:object[brojVrata:int, vozac:objekt, volan:string[left|right]]
@garaza:array<auto>
object[
garaza1:garaza,
garaza2:garaza
]"
// ..i sada ako kontroliramo strukturu nekog objekta sa gornjom validacijom, onda prolazi samo za objekt koji na ključu garaza1 ima garazu, te na ključu garaza2 ima garažu.
// I to je točno ovo što ti pričaš, samo u tvom slučaju imamo nešto tipa:
"
@myPassword: string{20-30}
object[pass:myPassword, key2:..., key3:...]"
I na ovaj način pisano, to su lokalne deklaracije klasa. Dok postoje i globalne, koje se mogu registrirati putem metode za registraciju novog singleType-a.
I kao što sam dao u uvodnom primjeru, registracija novog tipa se ne mora slagati samo iz komibnacije postojećih tipova, nego se pomoću funkcije može customizirat da bude bilo što. Primjer:
ADDING CUSTOM TYPES
addCustomControlType("strlen4", function(x){return isString(x) && x.length==4});
array<strlen4> -> za ulaz ["abcd", "efgh"] -> vraća true
Meni se uglavnom čini vrlo koristan alatić. 
Inspired by C#, hehe.
…a i bit će još toga, uvest ću relaciju “this”, tako da se može raditi komparacija na razini objekta, nešto tipa:
objekt[key1:string, key2:array{this.key1.length}]
isto tako i relaciju “this.parent”, kako bi se mogla raditi komparacija na različitim razinama objekta.
Recimo u gornjem primjeru sa autom i garažom, da se može postaviti uvjet da auto ispunjava nešto što garaža zahtjeva da ispunjava svaki auto koji joj pripada.
Pala mi je na pamet u međuvremenu još jedna primjena.
Ako se malo razmisli, jedan ovakva sintaksa nosi u sebi sve potrebne meta-podatke da se konstuira input forma.
Tako da bi za neke komponente to mogao biti jedan od ulaznih parametara po kojem će one izbaciti kompletnu input formu.
Ma primjene su razne. …i zato sam smatrao da je korisno izvući tu sintaksu iz razine compilera, i upogonit je u “ručnu” upotrebu. Kako će je netko koristiti, na njegovu volju.
Loša struktura ispliva sa 15 linija koda (vjerovatno zato i palamudiš u tomovima bez ikakvog koda).
Niti garaža niti auto ne treba da sadrži property vozač. Bilo bi zanimljivo vidjeti ostale akrobacije sa logikom relacija medju entitetima.
Postoji vec form validation na backend strani u skoro svakom boljem frameworku.
Nisam mislio na form validation na backend strani …nego sintaksa za automatsko kreiranje/generiranje forme + odmah dobiješ i validaciju koju spominješ.
Jer ako napišeš:
"
@auto:object[brojVrata:int, vozac:objekt, volan:string[left|right]]
@garaza:arrayobject[
garaza1:garaza,
garaza2:garaza
]"
- definirao si model auto i pravila njegovih propertya.
- definirao si model garaza i pravila njegovih propertya, gdje se vidi da je to relacija jedan naprema više, tj. da svaka garaža može imati koliko god auta.
Nadalje, konačno si rekao da tvoja forma traži da se unesu dvije garaže. …a svaka od tih garaža treba dopustiti da se unese n broj auta.
I sa vrlo malo sintakse smo kreirali podosta kompleksnu formu…naravno, mora postojati engine koji će gornju sintaksu prevesi u gotov HTML forme i dodati dinamiku toj formi da se omoguće relacije.
Nešto malo bi se gornja sintaksa samo morala proširiti…sa odgovarajućim labelsima i descriptionima…ali ono bitno je da se zadaju relacije i validacije polja koje forma mora osigurati prilikom unosa.