Toon posts:

[xml] standaard voor webformulieren?

Pagina: 1
Acties:
  • 169 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ik vroeg me af er al een soort van xml-standaard voor webforms bestaat.

Ik heb al naar XForms gekeken, maar dat is nog niet echt bruikbaar.

Ik zoek dus naar een xml standaard om een formulier te formuleren en die dan met een xsl stylesheet om te toveren naar een webformulier.

anybody?

Verwijderd

Mas*Mind: Ik vroeg me af er al een soort van xml-standaard voor webforms bestaat. Ik heb al naar XForms gekeken, maar dat is nog niet echt bruikbaar.
Omdat het een working draft is? Of vind je het idee nog niet bruikbaar?

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 31-08 10:19

D2k

het wachten is op mbravenboer :)

die weet het vast wel

Doet iets met Cloud (MS/IBM)


Verwijderd

Topicstarter
Arien > Ik bedoel meer eigenlijk dat ik nergens een concreet voorbeeld kan vinden. De voorbeelden zijn meer toegespitst op next-generation forms. Wellicht dat ik deze 'standaard' kan gebruiken, maar ik vraag me af of iemand dat dan al voor mekaar heeft gekregen: Zijn er al xsl sheets die deze definities om kunnen zetten naar forms in de huidige html-standaard? Ik vraag me dus af of er ergens een werkend voorbeeld te vinden is (nog niet gevonden)

Verwijderd

Mas*Mind: Ik bedoel meer eigenlijk dat ik nergens een concreet voorbeeld kan vinden.
Zou zo snel ook niet weten waar zoiets staat. Er stond een tijdje geleden wel een verhaaltje op www.xml.com.
Zijn er al xsl sheets die deze definities om kunnen zetten naar forms in de huidige html-standaard?
Ik heb niets gezien, maar je kunt die natuurlijk voor (een gedeelte van) de XForms welk maken.

Probleem is dat je voor het volledig iplementeren van XForms ook aan de client kant aan het werk moet. Aan de server kant een XForm naar HTML omtoveren is maar het begin (van veel moois ;)).

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Het gigantische voordeel van XForms is de manier waarop je de input binnen krijgt: XML. Dat is werkelijk magnifiek, want op deze manier kan je op een XML gebaseerde website dus ook gebruik maken van XML invoer. Je kunt op deze manier vrij veel structuur geven aan je invoer en het wordt veel eenvoudiger om via andere vormen invoer te doen (zoals bijvoorbeeld een client-side applicatie). Je kunt je bijvoorbeeld voorstellen dat er een Java GUI opgebouwd zou kunnen worden die een XFrom specificatie binnen krijgt en dus ook generiek werkt. De Java GUI verstuurd XML input naar de server.

Het grootte probleem op dit moment is uiteraard dat er nog geen (echte) implementaties zijn die ook daadwerkelijk XForms client-side kunnen afhandelen. Dat schiet dus niet op.

Je kunt nu heel moeilijk gaan doen door te trachten dit zelf een beetje te implementeren (is wel mogelijk: XSL stylesheet voor XForm -> XHTML, daarna een stukje server-side code die de traditionele input omzet naar XML), maar dat is wel behoorlijk lastig.

Makkelijker is dus om het gewoon dirty te doen. Uiteraard is het wel handig om zelf even een specificatie te verzinnen in XML vorm (eventueel een subset van XForms) en dit met behulp van XSL te stylen naar XHTML. Vrij ranzige server-side verwerking blijft echter noodzakelijk...

Leve de toekomst ;) .

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

mbravenboer: Het gigantische voordeel van XForms is de manier waarop je de input binnen krijgt: XML.
Nee, nee, nee... :) Je kunt de input als XML binnenkrijgen maar ook urlencoded bijvoorbeeld. Het enige dat er in de spec staat (IIRC) is dat de instance data (die gerepresenteerd moet worden alsof het XML is) geserialized wordt, maar niet in wat voor vorm.
Op deze manier kan je op een XML gebaseerde website dus ook gebruik maken van XML invoer.
Dat kan je nu ook wel doen met een paar regels code (uitgaande van een Apache module oid).
Het wordt [zo] veel eenvoudiger om via andere vormen invoer te doen (zoals bijvoorbeeld een client-side applicatie).
Je bedoelt een browser? >:)
Je kunt je bijvoorbeeld voorstellen dat er een Java GUI opgebouwd zou kunnen worden die een XFrom specificatie binnen krijgt en dus ook generiek werkt.
Het generieke is wat minder generiek dan het lijkt (zelf controls definieren is iets dat met XForms niet kan IIRC) en ik denk niet dat hier nou het grote verschil zit met bestaande (HTML) forms.
Het grootte probleem op dit moment is uiteraard dat er nog geen (echte) implementaties zijn die ook daadwerkelijk XForms client-side kunnen afhandelen.
Een echte implementatie heeft natuurlijk ook een "echte" spec nodig. ;)
Je kunt nu heel moeilijk gaan doen door te trachten dit zelf een beetje te implementeren (is wel mogelijk: XSL stylesheet voor XForm -> XHTML, daarna een stukje server-side code die de traditionele input omzet naar XML), maar dat is wel behoorlijk lastig.
Dan mis je naar mijn mening de belangrijkste onderdelen van XForms: validatie, XForms acties, reuse van controls, etc. XForms is 90% een client-side oplossing.

Nu nog wachten op de spec en XForms in Mozilla. :)

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Arien: Nee, nee, nee... :) Je kunt de input als XML binnenkrijgen maar ook urlencoded bijvoorbeeld. Het enige dat er in de spec staat (IIRC) is dat de instance data (die gerepresenteerd moet worden alsof het XML is) geserialized wordt, maar niet in wat voor vorm.
Owh, ok... zo goed had ik het nog nooit bekeken :) . Omdat het nog nerges echt gebruikt kan worden heb ik alleen m'n blik derover doen dwalen (das dus een disclaimer voor de rest van m'n verhaal ;) ).
[clien-side applicatie]Je bedoelt een browser? >:)
Duh ;) . Voor een stand-alone applicatie (neem Java ;) ) is het een stuk duidelijker om een stukje XML te versturen dan een url-encoded, post of wat dan ook. Ik doelde dus op client-side applicaties in het algemeen :) .
Het generieke is wat minder generiek dan het lijkt (zelf controls definieren is iets dat met XForms niet kan IIRC) en ik denk niet dat hier nou het grote verschil zit met bestaande (HTML) forms.
Ik bedoelde eigenlijk ook generiek voor simpele situaties zoals de huidige HTML forms. Uiteraard kan je wel generiek op basis van de standaard controls XML opbouwen uit de input van de gebruikers. Das dus een mooi generiek deel. Voor client-side applicaties die gebruik maken van web-services zou dat weleens erg makkelijk kunnen zijn...
Dan mis je naar mijn mening de belangrijkste onderdelen van XForms: validatie, XForms acties, reuse van controls, etc. XForms is 90% een client-side oplossing.
Gedeeltelijk mee eens. Ik had echter rekening gehouden met de huidige beperkingen van browsers, waardoor je deze features denk ik behoorlijk lastig kunt implementeren. Waar ik vooral op doelde is dat omzetting van url-encoded naar XML vorm wel server-side kan gebeuren. Op deze manier kan je dus 1 van de voordelen van XForms benutten. Omdat XForms sowieso nog niet echt gestandaardiseerd zijn heeft het ook weinig nut om je volledig aan die standaard te gebruiken. Een subset van XForms als toepassing zou daarom wel te doen/handig zijn.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

mbravenboer: Voor een stand-alone applicatie (neem Java ;) ) is het een stuk duidelijker om een stukje XML te versturen dan een url-encoded, post of wat dan ook. Ik doelde dus op client-side applicaties in het algemeen :) .
Om te maken is urlencoded data versturen natuurlijk veel eenvoudiger dan om die data in XML formaat te versturen. (Ik snap wel waar je heen wilt. ;))
Ik bedoelde eigenlijk ook generiek voor simpele situaties zoals de huidige HTML forms.
Hoe generiek is "generiek voor simpele situaties"? >:)

Waar het mij om ging is dat XForms je een mogelijkheid geeft om interactie via formulieren te definieren: controls, data binding, validatie, etc. Dat zijn allemaal oplossingen aan de kant van de client. De enige toevoeging voor serverside is dat je data als XML kunt opsturen (en je niet zoals nu voor het serializen van die XML je eigen wiel hoeft uit te vinden).
Gedeeltelijk mee eens. Ik had echter rekening gehouden met de huidige beperkingen van browsers, waardoor je deze features denk ik behoorlijk lastig kunt implementeren.
Je kunt een input filter in (bijvoorbeld) Apache hangen dat urlencoded POST data naar XML omtovert zodat voor al je serverapps het is alsof het als XML binnenkomt. Als je dat combineert met DOM/JavaScript client-side ben je waarschijnlijk al een heel eind in een moderne browser.
Waar ik vooral op doelde is dat omzetting van url-encoded naar XML vorm wel server-side kan gebeuren. Op deze manier kan je dus 1 van de voordelen van XForms benutten.
Eens, zie boven (en reactie hiervoor).
Omdat XForms sowieso nog niet echt gestandaardiseerd zijn heeft het ook weinig nut om je volledig aan die standaard te gebruiken. Een subset van XForms als toepassing zou daarom wel te doen/handig zijn.
Eens. Nu kan je niet veel anders omdat er te weinig vast ligt, maar zoals gezegd is XForms een clientside oplossing die een server bonus heeft in de vorm van POST data als XML.

  • mbravenboer
  • Registratie: Januari 2000
  • Laatst online: 06-11-2025
Arien: Ik snap wel waar je heen wilt. ;)
Das al heel wat ;) .
Hoe generiek is "generiek voor simpele situaties"? >:)
Goed punt ;) .
Je kunt een input filter in (bijvoorbeld) Apache hangen dat urlencoded POST data naar XML omtovert zodat voor al je serverapps het is alsof het als XML binnenkomt. Als je dat combineert met DOM/JavaScript client-side ben je waarschijnlijk al een heel eind in een moderne browser.
Inderdaad, in die richting zat ik dus ook te denken. Maar in welke mate zal het redelijk mogelijk zijn om een XForm specificatie om te zetten naar XHTML Forms + JavaScript? Ik werk niet veel met die JavaScript toestanden, dus heb daar helaas geen zicht op. Als dat goed te implementeren zou zijn, zou dat natuurlijk een gat in de markt zijn in de tijd voordat de grote browsers XForms ondersteunen....

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment


Verwijderd

mbravenboer: In die richting zat ik dus ook te denken. Maar in welke mate zal het redelijk mogelijk zijn om een XForm specificatie om te zetten naar XHTML Forms + JavaScript?
Kijk eens bij Mozquito voor een voorbeeld van wat er kan. :)
Ik werk niet veel met die JavaScript toestanden, dus heb daar helaas geen zicht op.
Ik werk bijna nooit (meer) met JavaScript maar ik weet wel wat ermee (icm DOM) kan en dat is genoeg (ik ga het zelf niet maken ;))
Als dat goed te implementeren zou zijn, zou dat natuurlijk een gat in de markt zijn in de tijd voordat de grote browsers XForms ondersteunen....
Implement W3C XForms in browser and composer is een openstaande bug voor Mozilla. Ik denk dat er wel iemand zo gek is om dit erin te bakken als de spec er is. ;)

  • tomato
  • Registratie: November 1999
  • Niet online
Arien:
Kijk eens bij Mozquito voor een voorbeeld van wat er kan. :)
Die zijn al een aardig eind :) (alleen zijn ze nog niet overal Mozilla compatible zo te zien |:( ).
Er komt wel een _enorme_ berg JavaScript bij kijken! Ik zie het toch echt als een tussenoplossing, maar het is wel een aardige.
Implement W3C XForms in browser and composer is een openstaande bug voor Mozilla. Ik denk dat er wel iemand zo gek is om dit erin te bakken als de spec er is. ;)
Maar dat zal waarschijnlijk nog wel even duren :?
Pagina: 1