Portál AbcLinuxu, 30. dubna 2025 18:09
4.6.2009 11:57
Salamek | skóre: 22
| blog: salamovo
4.6.2009 19:26
Jendа | skóre: 78
| blog: Jenda
| JO70FB
4.6.2009 20:11
Salamek | skóre: 22
| blog: salamovo
4.6.2009 12:46
Salamek | skóre: 22
| blog: salamovo
4.6.2009 14:44
Salamek | skóre: 22
| blog: salamovo
Což ale nic nemění na faktu, že má být zdokumentován ten komunikační formát, a ne "použijte tento program".
Naprostý souhlas, ale zaplaťpánbu aspoň za to, co momentálně je. S Fillerem je řada lidí nucena pracovat už tři roky, použitelný návod na rozběhání pod Linuxem se mi dosud nepodařilo najít. Program vždycky zamrzl při pokusu o otevření *.zfo souboru. Navíc, pokud už se konečně rýsuje linuxová verze, jak se uvádí níže v diskusi, je to víc, než jsem (asi nejen) já poslední tři roky doufal.
Pokud se nepletu, tak FormFiller je rozsireni formatu apache-fop. Kdyz rozzipujete xml soubor, tak jej otevrete potom v AbiWordu. Ale nevypada to dobre. Maji tam nejaka svoje vlastni rozsireni.
Aplikace-klient by se dala napsat velmi rychle. Format je relativne prehledny.
gf
Kdysi jsem to narychlo prohlížel a grafika je udělaná přes FO, pro lexikální validaci formulářových prvků používají XSchema, jednotlivé elementy adresují pomocí XPath a vyšší vztahy mezi prvky formuláře řeší nějakým podivným jazykem (něco mezi JS a pythonem).
Každopádně je skandální, že to není dokumentované a uživatel digitálně podepisuje jemu nesrozumitelný chuchvalec. Myslím, že takto podané to odporuje zákonu o elektronickém podpisu.
zdravim,
diky za kvalitni info.
Jak dlouho by jste videl implementaci desktopoveho klienta (prohlizec, odesilani) ? Lehky odhad mi vychazi asi na 2 clovekove-mesice prace i testovanim. Cilize do 100kKc fakturacne. Jak to vidite Vy ? A nemuselo by to byt nutne jenom opensource.
Je otazkou, jak by se zintegrovala na linuxu nejaka sprava certifikatu ?
Kdysi jsem si pohraval s myslenkou implementovat tyto veci jako firma. Bohuzel v soucasnosti mam kontrakt asi na 2 roky a linuxsoft zere vetsinu volneho casu. S apache-fop, desktopovym programovanim v Jave a PKI mam vcelku dobre zkusenosti.
Co se tyce popisu formatu, tak si myslim, ze 602-jka by podle me byla ochotna pustit specifikaci, ale i to by se asi zvladlo samo zpracovanim nejake mensi analyzy. Vychazim z minulosti, kdy se delal plugin do OpenOffice na formaty t602.
Co si myslim, ze je tezsi a vice stezejni, tak to je podle me FormFiller format. Nevite neco blizsiho o danem formatu ?
Dalo by se delat hodne v tomto smeru. Vize mam, ale v soucasnosti povazuji jako zasadni udelat financni rezervy v radu 100-200kKc, aby se to dalo rozjet. Pak se da temito kolecky hodne otacet a Linux a reseni na nem vice nasazovat. Ale toto jsou spise vize a supervize. Nerad o nich mluvim.
co jsem koukal do nize uvedeneho prikladu v priloze, tak asi nejvetsi problem jsou skripty. At jiz implementacni nebo okolo reseni bezpecnosti.
Víc vám neřeknu, protože jsem tenhle systém ještě v praxi neviděl (jen jsem prohlížel zdroják jednoho formuláře). U nás na obci se pravděpodobně zřídí Czech POINT, takže si to v létě omrknu.
Ohledně délky reimplementace záleží, kolik toho z jednotlivých technologií používají. Třeba FOP taky neumí celé FO. Pak taky půjde o specifikaci. Pokud se S602 sekne a pokud opravdu mění formát každou druhou verzi, tak to zas tak jednoduché nebude.
Pokud „formátem FormFiller“ myslíte odesílání dat na server, tak bych tipoval, že uvnitř formulářového souboru je XSL, kterým se vyrobí výstupní minimální XML, to se přes XMLSig podepíše a normálním HTTPS POSTem pošle na server. Ale jak už jsem říkal, tak nějaké jisté údaje můžu dodat až po průzkumu.
ok. Kdyztak mi poslete zkusenosti osobne, pripadne to nekde opublikujte a poslete odkaz.
Resenim formularu jsem se zabyval. Od vlastniho obecneho frameworku na tvorbu formularu, po vytezovani dat z jejich textove podoby.
Ono celkove jsou formulare prusvih. Existuje mraky reseni, ale nic neni jednotne.
Hodne se mi libly XForms. Bohuzel podpora neni nikde poradne doimplementovana(prohlizece, kancelarske baliky). Hezky format, ale zda se mrtvy diky podpore ze strany SW.
Potom z klasickych Word-souboru ci jinych dokumentu se da take neco delat s formulari. Bohuzel zde je tezke danou technologii v Linuxu uchopit.
Potom muzete vytezovat data z neceho prevedeneho do textu. To ale nemusi byt presne. Implementace neni zcela jednoducha.
Integrace do kancelarskych baliku. Hezke, ale dat do kupy build v nejakem IDE, to je na par dni a zda vubec. A pak jeste toto uchopit.
Takze ve finale vsude mame mraky webdeveloperu, kteri kazdy implementuji online formulare(obcas i stejne). Da se rici, ze vitezi, i kdyz z nejakeho komplexniho pohledu reseni na dve veci.
Dost dana idea pada na tom, jak rychle vyvijet a ze neni mraky veci doimplementovano. On ty chybi i nejaky standart co se tyce formularu, pripadne knihovna, ktere mi zobrazi dany formulare dle sablony na webu, desktopu, v konsoli a jak pak akorat resim mapovani dat do datoveho uloziste.
A jak z tohoto ven, tak to je otazkou.
zdravim,
zalezi jake xml elementy pouzivate. Soude podle toho, ze 602-jka bude mit nejaky vlastni editor a ten toho tolik umet nebude. Proto bych nevidel implementaci grafickych casti na tak dlouho. Jina ale, a to souhlas, muze byt treba plna podpora v textovem editoru.
Kolik je Vas nyni odhad v clovekomesicich v zavislosti na predchozim odstavci ?
Co se tyce projektu apache-fop (java, xmlgraphics), tak ten se trapi ruznymi vecmi. Nedostatek lidi, podpora java 1.4, slusny editor, obcas podpora IDE, ODF vystup, podpora tv textovych editorech,..... Jede to zejmena dle meho nazoru, co se tyce vystupu v PDF. Projekt da se rici stagnuje v hodne smerech. Odebiram jeho konferu, velmi drobne jsem vylepsoval podporu RTF formatu - pouzivali jsme v jedne firme. To by asi bylo na vetsi povidani mimo tema. Da se rici, ze clovek zjistil, ze potrebuje napsat analyzer RTF obsahu do stromu a ze podpora skvelych textovych editoru neni take idealni. Nebo, ze chcete od formatu prilis.
Jako člověk, který se setkává s 602XMLFiller profesně, se musím tohohle produktu zastat - skutečně slušně chodí a ulehčuje práci.
Co se provozování v Linuxu týká,myslím, že je rozumnější nainstalit do virtuálního stroje jakoukoli starší licenci Windows a 602XMLFiller provozovat tam.
My tohle řešení používáme. U uživatelů s nainstalovanými Linuxy se většina práce se odehrává v nich, jen když je potřeba občas použít nějaké speciální widle-only aplikace, tak se spustí virtuální widle. Naši uživatelé jsou zvyklí ukládat kamkoli na síti, kam mají přístup, a nečiní jim problém si to na jiné mašině, byť třeba virtuální, vyzvednout. Výuka začala postupnými kroky, nejprve v rámci sdílení peer-to-peer, postupně nabýval celý lokální systém složitosti se Samba fileservery, až se nakonec skončilo u centrálního datového úložiště. Uživatelé to berou tak, že skříň se šteláři a šuplíky na jejich počítači je rozšířena o snadno dostupné šuplíky a šteláře dalších skříní. Současně probíhal přechod na používání aplikací, které jsou na obou OS. Přesuňte jim složku Dokumenty na fileserver, nenechte je stažené ukládat na plochu a máte to vychytaný. Když ještě nastavíte Sambu jako PDC, můžete tam ukládat i wokenní profily jak pro widlí stanice, tak pro virtuální widle. Uživatelé pak budou brát svůj počítač jako jeden z možných "vstupů" ke své skříni s rozšířením o další skříně, k nimž budou moci přistoupit ze svých woken, z virtuálních woken nebo z Linuxu. Budou pak se sítí kamrádi a naučí se současně na Linuxech a jak bude přibývat multiplatformních řešení, budou widle stále méně potřeba.
Hm... ten filler vyplnuje offline XML? XML je prece normalni (skoro textovy) format? Neslo by to stahnout, odzipovat, vyplnit a znova zazipovat?
Zkuste si to. Případně se pochlubte, jak to šlo.
4.6.2009 12:06
Salamek | skóre: 22
| blog: salamovo
Nojo, tohle umím taky, ale vyplňujte to.
Nejsem si vědom toho, že by k té šabloně byla nějaká dokumentace. A i kdyby byla, tak si neumím představit ten opruz - ledaže by se našel někdo, kdo by si dal tu práci vytvořit open řešení. V geditu bych tohle fakt vyplnit nedokázal. Navíc ten formulář má pole, do kterého se vypočítává jakýsi obskurní kontrolní součet z vyplněných dat - tipuju, že algoritmus bude "výrobním tajemstvím", takže by se z toho programu musel vykutat reverse engineeringem.
4.6.2009 14:45
Salamek | skóre: 22
| blog: salamovo
Sorry, zkouset to nebudu, radsi venuju cas uzitecnejsim vecem. Jen naznacuju, ze kdyz uz ted neni XML cerna skrinka, tak by to v principu jit melo. Je jasny, ze struktura XML muze byt skutecne slozita, ale mame parsery, rozsahle pojednani o XUL a ja nevim o cem, takze treba pro me by bylo asi jednoduzsi si neco sam udelat nez vyvolavat cernou magii wine.
Pokud se bude porad XML pristupovat jak k nejake cerne skrince jeho predchudce tak se asi moc nezmeni, a reseni vsech problemu budou predpotopni. XML pred nami ale rozklada mnohem vetsi pole pusobnosti...
Před čtrnácti dny jsem si s nimi psal a dočkal se této odpovědi:
21.5.2009
Dobry den, v soucasne dobe nase spolecnost pripravuje a vyviji produkt 602XML Filler do prostredi LINUX, vyvoj jeste neni ukoncen, proto tento produkt jeste neni v prostredi Linux podporovan. S pozdravem a dekujeme za pochopeni
Tož uvidíme ...
Velké díky za tento zápisek. Dost mi zvednul náladu - s Fillerem jsem se dost trápil. Pokud jde o linuxovou verzi Filleru, tak tu už jsem dávno přestal vyhlížet - jsem rád, že jsem se spletl.
Dřív to pod wine nechodilo mj. proto, že ten program byl závislý na IE6 (nevím jestli tam bylo potřeba jen kvůli parsování xml, nebo jestli používali IE i k vykreslování obsahu okna). S přiinstalovaným IE6 ten program zatuhnul při otvírání formuláře (bez jakékoli chybové hlášky). Pokud je v těch balíčcích pořešeno aspoň toto (zřejmě je), tak je to rozhodně mírné zlepšení.
Nekdo by ty firme mel nafackovat
Nebo aspoň tomu, kdo tohle řešení vybral a nedotlačil je k tomu, aby funkční řešení pod Linuxem už dávno bylo.
Veskery SW hardkodovany na x86 a aktualni verzi Windows a MSVC.
Pod Vistama jsem osobně nikdy nezkoušel, ale teď si uvědomuju, že jsem to možná trochu zamlžil - ta závislost nebyla přesně na IE6, ale tuším to chtělo IE >= 5.5 Takže Visty IMHO nebyly "vyřazeny ze hry" jen kvůli novější verzi IE.
U nás to řešíme instalací na serveru do izolovaného prostředí v CITRIXu. Dávat uživateli práva něco si sám instalovat, je v prostředí, kde je 300 uživatelu sebevražda.
ve spolupráci, a teď se podržte s Novelem
Smutné.
různé šablony požadují k vyplnění ruzné verze fileru
A taky už minimálně jednou v minulosti změnili v nové verzi Filleru algoritmus na výpočet toho kontrolního součtu. To byla docela sranda, když se musel formulář odeslat mailem a zároveň fyzicky (přičemž kontrolní součty měly být stejné).
Na to, že 602 je součástí Noveláckého "ECO" systému od roku 2003. Byli jsme na jakési akci Novellu, kde Novell oznamoval fúzi se Suse a byli tam i ze 602 a slibovali podporu Linuxu. Ale zdá se mi, že slušné softwarové firmy se z nich stala neskutečná slibotechna. :(
4.6.2009 23:56
the.max | skóre: 46
| blog: Smetiště
Tož jsem tu beta 3 RC1 pro linux dnes otestoval (.rpm balík pro RH, (Centos) a Fedoru na i386 i x-64 verzi).
Stručně poznatky: jede to pod wine, instaluje se speciální úprava wine do /opt a homeuser adresáře. Nainstaluje to i plugin do mozilly (Firefoxu), samozřejmě i386, v x-64 OS se musí udělat symbolický odkaz v /usr/lib64/mozilla/plugins (případně plugins-wrapped) na příslušné "602" soubory v /usr/lib/mozilla/plugins (plugins-wrapped). Protože 602 xml filler nemá dosud jiný mechanismus, než přebírání certifikátů el. podpisů ze systémového úložiště woken, není zatím popsán způsob, kam a jak certifikát umístit pod wine, aby si to filler natáhl. Natažením certifikátu přímo do aplikace, jako je tomu např. Adobe Readeru, tedy filler zatím nedisponuje, formuláře lze úspěšně natáhnout do filleru, editovat je a uložit, ale nelze je tedy zatím podepsat. Problém je v asociaci formátu .zfo s prohlížečem - obsahuje-li některý adresář v cestě souboru nebo samotný soubor ve svém názvu diakritiku, plugin se sice rozjede, ale nenalezne poskytnutou lokální adresu souboru, takže se mu soubor musí poskytnou z toolbaru; nejde-li o tento případ, plugin načte soubor správně - plugin tedy není schopen adresu poslanou prohlížečem převést zpět na nativní znakovou sadu OS ( v daném případě UTF-8). Při chybách pluginu i při zavření prohlížeče a násilném ukončení případného dialogu o načítání souboru třeba pomocí Force Quit Button zůstává celá struktura od prohlížeče přes plugin až po wine podporu viset v paměti a musí se to všechno ručně killnout (zvláště je-li pokusů se stejným výsledkem více - paměti to žere hodně).
Závěr: je to betaverze a tedy doufejme, že v ostré budou popsané problémy odladěny. Že to není nativní a jede to pod wine celkem chápu z hlediska času, který byl k dispozici pro implementaci víceplatformního řešení v souvislosti s datovými schránkami (jiná věc je, že k tomu byli dotlačeni, kdyby to nerealizovali, nejspíš by ostrouhali mrkvičku). Koneckonců Soft602 se nejspíš inspiroval aplikacemi Google - Picasa a G.Earth. Dle mého názoru by však Soft602 měla začít práci na skutečně multiplatformním řešení nějakého nového XML Filleru, nejlépe od čistého stolu a nikoli za sebou táhnout wokenního kostlivce.
Také jsem testoval a to v souvislosti s demem datových schránek. Musím říct, že 602XML Filler RC1 není použitelný ani na tuto jednu speciálně ušitou aplikaci. Při pokusu o editaci oprávněné osoby se ve "formuláři" objeví jen bílá plocha posetá jakýmisi útržky dat. Zkoušel jsem rpm balík pro SLED na opensuse 10.3 i586. Takže do datových schránek jen s Windows.
Až na to, že v 64bitovém systému nemáte šanci a vzhledem k tomu, že bez toho d*bilní pluginu se v datových schránkách nepodá ani podání, tak kůli tomu bastlu od 602 je zabit jakýkoliv pokrok Linuxu ve firemním sektoru, neuvěřitelné, že to co sem si právě vyzkoušel prošlo a má fungovat od 1.7. :(. Osobně doufám, že už někdo odpojí firmu Software602 od státního koláče a nechá ji v klidu zdechnout.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.