IBM pracuje na přenositelném XForms 1.1 enginu (diskuse)

[Kyosuke]

To je skoro jako kopání do mrtvoly. Existuje vůbec nějaká použitelná a rozšířená implementace alespoň XForms 1.0 do webových prohlížečů, po všech těch (šesti) letech od jeho standardizace?

[Daniel Kvasnička ml.]

http://www.formsplayer.com/ -- pro IE a v budoucnu pro dalsi prohlizece

https://addons.mozilla.org/cs/firefox/addon/824 -- Firefox

Ty jsou pouzitelne, ne...? Co je ale zajimavejsi, je Chiba (http://chiba.sourceforge.net/), coz je servlet filtr, ktery umoznuje pracovat s XForms bez podpory v prohlizeci.

Podle toho, co sleduju, tak nekteri vyvojari XForms fakt berou vazne a pouzivaji to v produkcnim prostredi. Viz. http://www.oreillynet.com/xml/blog/2008/05/xrx_a_simple_elegant_disruptiv_1.html

No ale chce to vedet kdy to pouzit a kdy by bylo parsovani prijatych xf dat na serveru jen zbytecnym overheadem.

[Kyosuke]

http://www.formsplayer.com/ -- pro IE a v budoucnu pro dalsi prohlizece

Takže v současnosti si to ani nevyzkouším.

https://addons.mozilla.org/cs/firefox/addon/824 -- Firefox

Hmm, zajímavé - v době, kdy jsem to kontroloval naposledy, nevyplodil ten projekt žádný kód, který bych mohl vyzkoušet. Díky, na tohle určitě kouknu.

Co je ale zajimavejsi, je Chiba (http://chiba.sourceforge.net/), coz je servlet filtr, ktery umoznuje pracovat s XForms bez podpory v prohlizeci.

Tak to je právě naprosto nezajímavé. Důvody:

• Drze to předpokládá, že mám v úmyslu na straně serveru používat Javu (a ztrojnásobit tak paměťovou náročnost vlastní aplikace jenom kvůli formátu, o kterém se klient ani nedozví, a mohl bych tedy téhož výsledku dosáhnout i jinak a nikdo by nic nepoznal).
• Drze to předpokládá, že cítím potřebu definovat formuláře na straně serveru v XML (protože můj jazyk je tak ubohý, že nedokáže vyjádřit formulář třeba jako deklaraci třídy, přičemž o vhodné mapování datového modelu definovaného v deklaraci třídy do kódu posílanému klientovi se postará CLOSová metatřída).

Nespadám ani do jedné ze skupin, které mají takovéto potřeby, natožpak abych spadal do jejich průniku. Domníval jsem se, že XForms jsou hlavně formát pro komunikaci serveru s klientem, a že největší přínos mají v okamžiku, kdy existuje alespoň jeden dobře použitelný, jednoduše instalovatelný a funkční klient, tím spíš, pokud je to něco, co většina lidí instaluje z vlastní vůle (třeba přímo webový prohlížeč, klidně i Firefox s doplňkem), který umí formuláře dostatečně rozumně a tuto funkcionalitu exponuje právě pomocí XForms. Přičemž čím víc klientů je na výběr, tím lépe. Server-side řešení pro mě tuto eleganci určitě nemá.

Podle toho, co sleduju, tak nekteri vyvojari XForms fakt berou vazne a pouzivaji to v produkcnim prostredi. Viz. http://www.oreillynet.com/xml/blog/2008/05/xrx_a_simple_elegant_disruptiv_1.html No ale chce to vedet kdy to pouzit a kdy by bylo parsovani prijatych xf dat na serveru jen zbytecnym overheadem.

Uá, tam ty zobáčky fakt žerou k snídani či co. Když mám SXPath, XQuery moc nepotřebuju. Ale jestli jim to slouží dobře, přeju jim to. Díky za ten firefoxí addon, kouknu na něj a třeba mě to příjemně překvapí. Od doby, co jsem před dvěma nebo třemi lety zhnusen stojatými vodami XForms přestal situaci sledovat, snad k nějakému vývoji došlo.

[Daniel Kvasnička ml.]

Drze to předpokládá, že mám v úmyslu na straně serveru používat Javu

No jo, no... at by to bylo pro jakoukoliv server-side technologii, vzdycky by to nekdo vnimal jako "drze to predpoklada, ze to budu psat v XYZ"

Drze to předpokládá, že cítím potřebu definovat formuláře na straně serveru v XML

To nevim, co myslite. Na strane serveru nic nedefinujete. Pisete normalni XHTML+XForms jako kdybyste predpokladal plugin u klienta, akorat ze ten jejich XFormsFilter vam skoci do response a zchrousta to tak, ze ke klientovai dorazi jen XHTML a JS. A naopak pri odeslani formulare skoci do requestu a vam pak prijde v jakemsi parametru ten naplneny XML model.

můj jazyk je tak ubohý, že nedokáže vyjádřit formulář třeba jako deklaraci třídy, přičemž o vhodné mapování datového modelu definovaného v deklaraci třídy do kódu posílanému klientovi se postará CLOSová metatřída

To ja zase nevim, proc by server vubec mel vedet neco o nejakem pojmu formulare. Ja chci luxusni podporu indexovanych properties a data bindingu tak, aby mi data z formulare "zaplula" tam kam maji, prip. byla zvalidovana. Co se tyka XForms, tak tam opravdu vidim smysl pouziti spis v pripade pouziti nativnich XML databazi. Mozna tak jeste XForms odpoved z klienta & XSLT -> SQL ...

Uá, tam ty zobáčky fakt žerou k snídani či co. Když mám SXPath, XQuery moc nepotřebuju. Ale jestli jim to slouží dobře, přeju jim to.

No jak tam pisou. Pokud mate treba eXist jako DB, tak ty formularovy data jako XML jsou fakt asi nejprimocarejsi reseni... A ackoliv muze nekomu pri vysloveni slova XML naskakovat husi kuze, tak nativni XML databaze jsou pri reseni silne dokumentove orientovanych problemu nebo praci s hodne hierarchickymi daty rozhodne lepsi nez relacni databaze (jeste jsou tu objektove, tam je podle me taky cast budoucnosti a vy urcite mate v rukavu nejakou Lispovou silenost )... Jak rika Elliotte Harold, 80 % svetovych dat vubec neni urceno pro skladovani v relacnich DB, ale tech zbylych 20 % bylo pro lidstvo tak dulezitych, ze stravilo 20 poslednich let cpanim tech dat do relacnich DB.

[Kyosuke]

To nevim, co myslite. Na strane serveru nic nedefinujete. Pisete normalni XHTML+XForms jako kdybyste predpokladal plugin u klienta, akorat ze ten jejich XFormsFilter vam skoci do response a zchrousta to tak, ze ke klientovai dorazi jen XHTML a JS. A naopak pri odeslani formulare skoci do requestu a vam pak prijde v jakemsi parametru ten naplneny XML model.

Jo takhle. Já bych samozžejmě ten kód generoval z modelu, nepsal bych ho ručně (ani bych o to moc nestál). Ale ono to asi stejně bude hodně zahákované do servletů a JSP, předpokládám. Dělat z toho samostatný filtr jako proces by nemusela být sranda. A ještě je tu jedno riziko, a sice impedance mismatch mezi datovým modelem XForms (předpokládal bych dtové typy z XML schémat) a datovými typy jazyka aplikace.

Takže nakonec, dám-li dohromady více kritérií, vychází mi z toho, že takové řešení by pro mě nebylo dvakrát lákavé. Plnohodnotní XForms klienti na druhém konci drátu mi přijdou mnohem zajímavější, ale už příliš dlouho se na nějaké těším bez radosti z hmatatelnéjo dárku. Tahle možná bude lepší, když se kouknu na Web Forms 2.0 jako "odlehčenější" řešení. Sice to má taky implementační zletilost ještě před sebou, ale Opera už to implementuje skoro v úplnosti.

nativni XML databaze jsou pri reseni silne dokumentove orientovanych problemu nebo praci s hodne hierarchickymi daty rozhodne lepsi nez relacni databaze (jeste jsou tu objektove, tam je podle me taky cast budoucnosti a vy urcite mate v rukavu nejakou Lispovou silenost ).

Jistě že (SWF) mám (SWF), jak jinak? Odkazované řešení, kdybych ho měl ve Scheme, by byl takový malý splněný sen. Ale kdo ví, teď, když jsem našel možná velice vhodný a pěkný (japonský ) backend pro něco podobného...

[Daniel Kvasnička ml.]

Ale ono to asi stejně bude hodně zahákované do servletů a JSP, předpokládám. Dělat z toho samostatný filtr jako proces by nemusela být sranda.

No, jasny, je to standardni J2EE filtr podle specifikace, takze predchazi bud servletu, JSP nebo dalsimu filtru.

A ještě je tu jedno riziko, a sice impedance mismatch mezi datovým modelem XForms (předpokládal bych dtové typy z XML schémat) a datovými typy jazyka aplikace.

Jasny, XML Schema. To ale zase odpada pokud fakt berete v uvahu tu nativni XML databazi. Proto je podle me ten autor toho clanku o XRX z toho tak vodvarenej... jak popisuje tu svou prai na nejakem realitnim IS.

Tahle možná bude lepší, když se kouknu na Web Forms 2.0 jako "odlehčenější" řešení.

No jo, taky moznost. Furt lepsi nez neco na zpusob mikroformatu, kde se stavajici atributy zneuzivaji k ukladani informace uplne jineho typu... z toho se mi zaludek obraci.

[hikikomori82]

Prave robim jeden vacsi projekt v XUL-e ale je to peklo na zemi. Keby sa niekto dokopal k niecomu pouzitelnejsiemu, vrelo to uvitam.