O el. formulároch sme tu už na platforme veľa diskutovali. Aj konkrétne, povedme za mňa pri novele z. o eGov §24.2, §24.3.
Ale áno, elektronické tlačivá majú zmysel.
pevne daná štruktúra pre údaje k určitému podaniu - môžem ju napr. ľahko vyplnenú generovať v mojom vlastnom SW
oddelenie obsahu od formy - možnosť strojového spracovania
zobrazenie vyplneného formulára - vždy jednotné, raz vopred pripravené
vytlačenie na papier - ak sa z ľubovoľných dôvodov nebude pokračovať elektronicky, či už prázdne, alebo s údajmi
Rozhodne nech sú elektronické tlačivá dostupné. Povinné minimum: holé, bez akýchkoľvek napĺňaco, validačo, nápovedo, tlačítkových vylepšení. S minimalistickou vizualizačnou transformáciou. Kto chce a má dôvod (vyjde mu CBA ), nech si v pohode robí aj nadštandard.
Už menej je jasné, či má zmysel povinne robiť “vo formulári” dokumenty, ktoré nie sú schematické. Povedzme rozhodnutia, taký @ius má na to dosť vyhranený pohľad.
Áno, možné to je. Aj ten XSLT je výpočtovo úplný. Len s akou námahou… (ten odhad pre doručenku ma ozaj zaujíma)
Otázka, či sa dá nájsť formulár, ktorý sa nedá urobiť v xform, pre mňa nie je zaujímava. Otázkou skôr je, že či to poskytne ideálne ux, či vývoj nebude drahší ako v inej technológii, či sa to bude dobre udržiavať.
Ani sa mi nepáči, keď sa povie, že áno, terajšia upvs technológia nebola ideálna, ale už bude. Neverím. Keď po deployi formu na vývojové prostredie upvs musím čakať deň na jeho schválenie, aby som ho mohol vyskúšať, tak to doslova paralyzuje vývoj a pojmy ako continuos delivery sú absolútne nedosiahnuteľné a žijeme vďaka tomu v minulom tisícročí. Chápem, že sa to dá zlepšiť. Ale je tam obrovské riziko, každý nedostatok centrálneho komponentu ovplyvňuje všetkých.
Pre mňa otázka nie je “ukážte čo sa v tejto technológii nedá”. Pre mňa je to, vysvetlite mi, čo za výhody centrálna technológia prinesie, aby to vyvážilo riziká. A ignorovať prevádzkové problémy (kým sa nová centrálna technológia nasadí, pripravia tooly, prostredia … budeme zase na konci programového obdobia a medzitým sa systémy urobia nejako ináč ) je nemožné.
K iomo. Áno chápem, že jednotná technológia pomáha tomuto konceptu. Ale nezafungovalo. To je ako komunizmus, bolo by to krásne, ale v praxi sa to vždy nejako zvrtne. Zda sa mi prirodzené, ako píše Jano, že by sa to riešilo zastupovaním. A ak úradník k tomu potrebuje mandátny certifikát, tak mu ho dajme.
to co popisujete zas tak zlozity formular neni. nieco inak postavene ako toto avsak malo to prvky tohto som ukazoval aj na PS6. totizto xform popisuje aj to ako sa ma prvok zobrazit a tu napriklad vieme ze memo pole zobrazime ako html textarea avsak mam moznost pouzit uzivatelsky definovany atribut apearance a tym pokial mi to dana implementacia dovoluje a ja nadefinujem napriklad pre textarea appearance=“MCE” tak formular vyrenderuje textarea ako timiMCE editor.
Priklad z mapou sa da riesit obdobne, napriklad zadanie suradnic spravim tak ze sa budu v XML ukladat do memo pola v definovanom tvare, na to spravim validaciu a co sa tyka zobrazenia pre zadavatela tak napriklad mozem spravit to ze dam znova textarea a appearance=“GoogleMap” nuz a ak mi to implementacia xforms povoluje tak zobrazim tu google mapu kde proste vyklika co chce, ulozi sa mu to do toho memo v danom strukturovanom tvare . pokial tu mapu implementacia nema lebo hold niekto pouzije inu implementaciu, tak mi zobrazi len to memo a zapisem tam tie veci ako text , ale validacie nad tym polom mi to v oboch pripadoch zvaliduju korektne. Nejaky custom field som uz ukazoval na viac prezentaciach, v mojom pripade som vsak pouzil hand writing pole tj keby som chcel mat formular napriklad na tablete a chcel aby mi ho obcan rucne podpisal… v takom pripade to podpise a do XML sa ten podpis stransformuje a ulozi ako base64 string
tie kroky ze co prve a co druhe a co sa zobrazi ak zaskrtnem ine pole. toto nie je problem v xforms, tu su podporovane udalosti, kde napriklad na zmenu polozky sa vola udalost. v ramci nej viete zobrazit /skrit inu cast formulara, viete nastavit hodnotu v XML na zaklade zvolenej polozky, viete spustit validaciu casti formulara,… Ten autocomplete je tiez podobny custom field ako ta mapa alebo ten handwriting co som popisoval… tj ano toto vysie sa da spravit
Tu vsak ste mozno narazili na iny problem, tj aku uroven detailizacie vobec mam vyzadovat aby obcan o sebe ako ziadatelovi vyplnal, nakolko pokial ma stat uz teraz udaje o mne ako cloveku/firme tak nebudem mu posielat tieto udaje, obzvlast pokial institucia je povinna si ziadatela stotoznit a prevziat a pracovat s udajmi ktore o obcanovi ma z referencnych registrov
Toto by bol dobrý hackathon. Dá sa téma, čo ja viem, služby živnostenského registra, k tomu back-end API a dáta (na hackathon postačia demo) a nech každý tím skúsi spraviť front-end na svojej paradigme po krok mám-hotové-podanie-pred-podpisom.
Tak teda naco potrebujem tu vyplnaciu cast vo formulare? Naco by som si ju zvolil? Naco ta kooxistencia? Papiere nikto nechce rusit. Nech zostanu, rovnako ak pridete na urad nach su tam kludne… my vsetci hovorime, ze nema zmysel centralizovat technologiu pre zber udajov - teda GUI elektronickeho formulara.
slovenska implementacia formularov sa skusila a vypadli z nej nasledne nevyhody:
dizajner je nepouzitelny, nevie spravit zakladnu vec - importovat existujuci formular (teda nemate priklad), pracuje s internym formatom a formular je iba na vystupe - export
duplicita biznis logiky - ak raz robite backoffice, tak robite aj rozhrania pre prepis “papierovych” podani, tento kus kodu by ste z casti vedeli prepouzit aj na GUI pre verejnost, avsak nie v elektornickych formularoch, takze programujete este raz to iste
neflexibilne zmeny - ak potrebujete opravit nejaku drobnost v GUI, musite registrovat cely formular, co nie je uplne trivialny proces
toto cele zbytocne predrazuje projekty a nic to neprinasa
Formular teda nech zostane predpis - datovy a vizualizacny, GUI osetrime dizajn pravidlami
BTW: argument, ze to bude pre IOMO uz prosim nie… je to cisto pseudoargument, jednak ako @jsuchal spominal okrem vypisov kto robi realne nejake ine iomo? A keby sa velmi chcelo, tak sa da zabezpecit aby pracovnici IOMO mali pristup priamo k GUI formulara, ktoremukolvek nech je naprogramovany v comkolvek. A uz to zopakujem asi tisici krat, fakt si myslite ze nejaky pracovnik na poste alebo obecnom urade bude vediet za vas vypnit a podat ziadost o davku hmotnej nudzi a zaroven zaregistrovat sro a zaroven ziadost o evidenciu motoroveho vozidla atd…
BTW2: ako to tu citam podrobne… tak som napisal to iste co vsetci predmnou a ok hackaton na gui pre formular je ok, len sa mi zda divne ze ideme znova dokazovat to co uz v praxi sa prejavilo - to je akoby som mal na dialnici rozbity asfalt a chcem predsa len laboratornu skusku, ze je rozbity, ale to je typicky slovenske a zistujem ze sa uz tomu ani nedivim
vsak ale este raz xforms je definicia formulara. xforms nie je konkretna implementacia. Pokial si zoberiem napr angular ako framework tak spravim implementaciu xforms s angularom. pokial si zoberiem xcode a spravim implementaciu pre IOS tak to budem mat v tom…
netrval by som na centralizacii aby vsetko nutne muselo byt na UPVS, tu mi hlavne islo o to ze by bolo dobre najst take riesenie ktore by umoznovalo aby institucie mohli mat u seba eformulare a ci to budu klasicke eforms alebo wizardy to je uplne jedno. podstatne by malo byt aby to bolo standardizovane do tej miery ze implementacia bude vymenitelna a nie zavisla na nejakej mega firme ktora sa tym zabetonuje v nejakej institucii a nebue ju mozne vymenit
hej ved tak som to aj myslel, vsak ale bavili sme sa vecer, je rano odpisal som aby som popisal moznosti. Napriklad v ramci toho ze mna osobne cela tema xforms zaujima som zacal uplne nezavazne pre nikoho proste tak pre seba si riesit implementaciu v nejakej a uplne teraz je jedno v akej technologii, z pohladu toho co pozadujete napr autocomplete nemam implementovany - rovnako ako mapu nie, ale ako som pisal vyssie standard to umoznuje spravit. Napr ale free implementacia Orbeon ma dokumentaciu tak kuknite sa https://doc.orbeon.com/form-runner/component/autocomplete.html
mate na to zadanie schemu a xml ? resp eform balik bez tej editacnej schemy ?
doplnim este sam seba, ten autocomplete do implementacie je v rieseni, ta mapa taktiez. tj nevravim ze vam to poslem zajtra ale pokial poslete schemu a xml tak to spravim a pak si mozeme niekde sadnut a na zivej ukazke si mozeme prejst to ake moznosti to ponuka.
no ale ak potrebujem opravit eformular tj napr GUI na html transformacii tak proste nemate riesenie ktorym by ste to spravili bez zmeny verzie. tu vam nevyriesi problem to ze si kazdy bude robit eform jak chce. Registracia je proces ktory sa na zaklade poziadaviek zakaznika (Nases) nejako nastavil. v tomto smere su rozne uvahy a diskusie ako by to malo byt a ako by sa to malo zjednodusit, treba si ale uvedomit ze tym ze eformular niekde registrujem tak ten eform musi v konecnom dosledku sa synchronizovat jednak do XY modulov v ramci UPVS a jednak do XY modulov inych ISVS ktore dany eformular mozu prijat, ci uz priamo v ramci vlastneho podania, alebo nepriamo formou priloh, rozhodnuti od inych institucii a podobne… tj nemozete ocakavat ze vy spravite eform a v momente ako ho niekam poslete ho vie kazdy ISVS na SR prijat a spracovat, to je nerealne
pre ucel prezentacie co som ukazoval na par miestach som prerabal nejaky VUC formular, to co som pisal ze uz napr v implementacii co som ja riesil mam podporovane je to co dnes realne sa v tych mne znamych eformularoch pouziva a co boli aj niektore body v tom opise zadania co tu bolo poslane. tj podmienene zobrazovanie, kaskadove ciselniky, moznost zobrazenia eformulara ako klasickeho formulara ale napr aj formou wizarda kde jednotlive sekcie viem spravit ako kroky wizarda, ono toto je taka tema co lepsie ukazat na ukazke a bavit sa co sa da/neda ako striktne niekoho presviedcat ze preco prave toto v podstate mne osobne je uplne jedno ci to bude xforms, mne len islo o to a to sa asi uz opakujem aby editacna transformacia bola reimplementovatelna, tj aby zas nenastal o par rokov obdobny problem s tym rozdielom ze teraz tu je jeden centralny upvs eform dizajner a o par rokov ich tu bude 10 , kazdy na inej technologii , kazdy nestandardizovany a vzajomne nevymenitelny
Je to napísané v inom dokumente, ktorý sa schvaľoval pár mesiacov skôr.
Je tam napísané “majú” (podľa mňa je to odporúčanie a vyložia si to tak aj ďalší) a nie “musia” (povinnosť). Tu sa síce hrám so slovíčkami, ale na Slovensku sa s nimi aj v týchto projektoch hralo vždy, tak prečo si máme myslieť, že to teraz bude inak?
Čo je zlé na tom, keď sa tá povinnosť zopakuje aj v tomto dokumente a jasnejšie? Takto mi to pripadá, že je práve problém v tom, nezopakovať to jasnejšie, pretože to tak niekomu vyhovuje.
No to nemam, a velmi ma eform balik ani nezaujima. Mam ten “wizard” co sa da preklikat. Podme si na tom ukazat dokonaly svet a ako mi v tom pomozu xforms/form designer…
Co uz spominali predomnou - Cize ten flow je aky? Ked zistime, ze nejaky prvok novy potrebujeme, tak sa rozbehne standardizacna masineria? Ja to napriklad velmi dobre poznam z uplne primitivne vyzerajuceho prikladu- autoform Automatické výpĺňanie údajov o firmách. · Autoform. Clovek si povie, ze co na tomto moze byt take komplikovane. No lenze, zacne to poziadavkou - chceme tam len aktivne firmy, potom len firmy z nejakeho kraja, firmy co nie su platci dph, len platci dph podla nejakeho paragrafu. Potom vlastne by bolo dobre, aby si to pamatalo tie firmy co pouzivam casto, atd atd atd. Jednoducho ked chcem spravit spickove UX tak centralizacia to cele zarovna na jednu uroven priemernosti.
Nie je relevantné, či sa dokument schvaľoval alebo neschvaľoval “pár mesiacov skôr”, buď platí, alebo neplatí. Tento platí.
Áno, už sa hráš sa so slovíčkami, ale skúsme objektívnejší výklad: Slovenské slovníky
II. vo funkcii modálneho slovesa 1. (s inf.) vyj. a) nevyhnutnosť, potrebnosť, povinnosť:m. sa veľa učiť, zajtra sa má ísť domov b) možnosť konať dej: čo má robiť? ako to mám vedieť?
Pri “možnosti konať dej” si všimni, že sa vždy jedná o otázky (ak by som chcel oznamovaciu vetu,musel by som tam doplniť “… majú možnosť…” - pri oznamovacej vete je výklad jasne v rovine povinnosti, potrebnosti, nevyhnutnosti
Nie je na tom samozrejme nič zlé, len si písal, že vnímaš že “dokument umožňuje rôznu interpretáciu niektorých častí, takže každý si tam nájde to čo chce”. Tak v tomto konkrétnom prípade nie, ok?
no ale bavime sa o eformularoch tj pokial chcete priklad vychadzajme z toho co riesime. preto som pytal schemu. Eformular vnimam kus zlozitejsie ako to co pisete vy, totizto tam musim pouzivat prvky z katalogu datovych prvkov a napr pre ciselnik jednu polozku uz naplnam 3 minimalne hodnoty do XML (kod ciselnika, kod ciselnikovej polozky, text) v pripade kaskadovych ciselnikov to boli kontroly a mazania hned cez niekolko takychto datovych prvkov. tj ukazat vam priklad, ktorym sa vyriesi nejaky biznis problem nejakej firmy nema zmysel v kontexte toho co som pisal.
no ale este raz k podstate aky prinos to bude mat voci existujucemu stavu ktory je dnes, co vlastne je tam nova myslienka ? pisal som vyssie, uz dnes to co ste napisali ze formulare budu v kompetencii ISVS realne tak funguje, tu len dostanete na oficialnu uroven situaciu aka dnes je. Mne to pride ze tym akurat odobrime rozbehnuty biznis niekolko dalsich firiem ktore svoje vlastne proprietarne riesenia budu ponukat na dalsich XY institucii, tj nic nove, len nebude jedna technologia ale dalsich 10 resp kolko ich dnes mame na SR… A neverim ze natolko univerzalnych aby som v nich nieco spravil bez dalsieho zasahu. Proste problem bude v tom ze tych 10 medzi sebou nezamenim bez zrejme pak uz pomerne velkej investicie, tj aku usporu financii / zlepsenie toto vlastne prinesie ?
Predpokladám (opravte ma prosím, ak sa mýlim), že uvedený dokument SP Referenčná architektúra v praxi bude znamenať, že sa:
nezmení povinnosť publikovať e-formuláre v MEF,
zmení sa len rozsah toho, čo tieto e-formuláre budú musieť povinne obsahovať, najmä to, že súčasťou e-formulára v MEF už nebude povinne prezentačná schéma pre vypĺňanie,
nebude sa pravdepodobne nič meniť na tom, že e-formuláre v MEF musia povinne obsahovať:
definíciu dátovej štruktúry (XSD),
podpisovú prezentačnú schému (XSLT do TXT, HTML alebo XHTML)
tlačovú prezentačnú schému (XSLT do XSL-FO pre konverziu referenčným XSL-FO procesorom do PDF)
Toto je imho tiež príklad pre oddelenie čo najviac funkčnosti “preč” od el. formulára.
Ale pre mňa je ozaj podstatný ten koncepčný pohľad. Roky už “podávam daňové priznanie” tak, že “vypĺňam formulár daňového priznania”, v ktorom 80% položiek je prázdnych a ďalších 10% sa kopíruje z predošlých políčok. Je úplne zbytočné, aby gestor tejto životnej situácie špekuloval, akou technológiou tie prázdne položky a sekcie “skryť” a ako položky “automatizovane kopírovať”.
Veľmi by som ocenil interaktívnu aplikáciu, ktorá má niekde voľbu čo ja viem “príjem z dividend”, a ak ju nepoužijem, skrátka sa s tým nič nerieši. Vyklikám si tých zopár zdrojov príjmu čo som mal, vyplním k tomu údaje a v pohode nakoniec nech to vygeneruje ten 15 stranový, vyplnený a predsa skoro prázdny, el. formulár.
no ale predstavte si ze date eformular ktory ma jedno xslt ktore moze byt sign/view no a pak zistite ze tam je preklep. tym ze by ste to chceli zmenit v tom xslt tak proste bez zmeny verzie to nepojde. napisat ze cim viac veci prec o eformulara, no skuste napisat aka je predstava vasej definicie co by mal obsahovat eformular, ake suvisiace dokumenty a za akym ucelom by tam boli a skuste popisat aj to akym sposobom by ste menili formulare.
), nech si v pohode robí aj nadštandard.
odpisal som aby som popisal moznosti. Napriklad v ramci toho ze mna osobne cela tema xforms zaujima som zacal uplne nezavazne pre nikoho proste tak pre seba si riesit implementaciu v nejakej a uplne teraz je jedno v akej technologii, z pohladu toho co pozadujete napr autocomplete nemam implementovany - rovnako ako mapu nie, ale ako som pisal vyssie standard to umoznuje spravit. Napr ale free implementacia Orbeon ma dokumentaciu tak kuknite sa