Mozilla-project gaat werken aan implementatie XForms

Op de site van Mozilla is te lezen dat de open-source-organisatie achter de browser is begonnen aan de implementatie van XForms. Voor dit nieuwe project is een samenwerkingsovereenkomst gesloten met IBM en Novell, die gaan helpen bij de implementatie van XForms. Voor het nieuwe project is op de site van de Mozilla Foundation een apart gedeelte ingericht waarin het project wordt beschreven en waar de voortgang wordt bijgehouden. De implementatie die de drie instanties gaan maken zal conform de richtlijnen van het W3C zijn zoals beschreven in de recommendation voor XForms 1.0.

XForms moet de opvolger worden van de huidige HTML-forms die elke computergebruiker die regelmatig op internet surft wel eens is tegengekomen. De HTML-forms worden vaak gebruikt voor zogenaamde webapplicaties voor de invoer van gegevens. Er zijn echter de nodige beperkingen en onvolledigheden aan de huidige HTML-forms die in XForms opgelost zullen worden. Zo voorziet XForms in de mogelijkheid om client-side gegevensvalidatie uit te voeren, de ingevoerde data in XML naar de server te versturen (HTML-forms bieden alleen de mogelijkheid om eenvoudige key/value-paren door te sturen) en zal de presentatie en de onderliggende data voor XForms volledig kunnen worden gescheiden. Ook is de beschrijvingstaal voor de formulieren in XForms eenvoudiger en zal het mogelijk zijn om formulieren eenvoudig op verschillende manieren te tonen, bijvoorbeeld via WAP en HTML.

XForms 1.0 maakt onderdeel uit van de XHTML 2.0-specificatie. Deze beide standaarden zijn gebaseerd op XML en voorzien in de mogelijkheid een goede scheiding tussen data en presentatie aan te brengen - een essentiële eigenschap van een 'nette' applicatie. Dankzij XForms 1.0 zal het in de toekomst mogelijk zijn om geavanceerdere en eenvoudigere webapplicaties te ontwikkelen. De implementatie van XForms 1.0 is echter nog een flinke klus aangezien de standaard rust op andere XML-standaarden zoals XPath en XML Schema. Deze twee standaarden zullen eerst moeten worden geïmplementeerd door de ontwikkelaars van Mozilla teneinde XForms te kunnen ondersteunen.

Reacties (43)

[jurrie]

Helaas huppelt bijna de hele wereld nog vrolijk rond in een browser die al 4 jaar lang achterhaald is en waar ik voorlopig geen XForms (of andere nieuwe dingen, buiten die paar die recentelijk zijn aangekondigd) in zie verschijnen.

Fijn dat Mozilla en Opera en consorten in sommige dingen erg vooruitstrevend zijn en de nieuwe recommendations van het W3C implementeren, maar zolang het overgrote deel van mijn gebruikers (geen websites, meer webapps) dit niet kunnen zien, kan ik hier nog niets mee >_<

[Zaagmans]

Tenzij je JOUW gebruikers weet over te laten stappen naar FireFox (of Opera). Tegenwoordig echt niet meer zoŽn enorme operatie...
Er zit zelfs een hele wizard bij die je begeleid bij het overzetten van je favorieten e.d. vanuit IE naar FireFox.

[jurrie]

laten "mijn" gebruikers nou net leerlingen van ROC colleges zijn. Niet enkele tientallen, maar duizenden. Zie al die scholen maar eens volledig over te laten stappen, en dan natuurlijk ook nog alle studenten op hun thuiscomputer en laptops.

Voorlopig blijft het minimaal 3 browsers testen voor mij ^_~

[SiliconError]

Er wordt bij Microsoft in ieder geval weer nagedacht over een nieuwe Internet Explorer (zie het topic op GOT). Misschien wordt het in de toekomst wat beter voor webdevvers

En trouwens, hoeveel mensen gebruiken er op dit moment XHTML 1? Juist. Tegen de tijd dat XHTML 2 en XForms er zijn, dan is Microsoft al bij IE 8.0 (in 2009 ofzo )

Tegen die tijd zien we wel weer hoeveel mensen er nog rondsurfen op de zwaar verouderde IE6, en Mozilla Firefox 0.9

[dotnetpower]

En trouwens, hoeveel mensen gebruiken er op dit moment XHTML 1?

Ik, zouden meer mensen moeten doen, krijg je tenminste (mits je de regels volgt) geen gaar opgemaakte wegpagina's met code die voor geen kant klopt, maar welke dus enkel in IE goed wordt weergegeven.

[Anoniem: 112954]

Het verschil met XHTML is dat verkeerde XHTML gewoon niet zal worden weergegeven. Moet je niet telkens naar de validator hollen, en moet je als browser-bouwer ook geen "quirks mode" meer gaan maken die andermans fouten probeert recht te trekken.

En aangezien XHTML eigenlijk gewoon XML is, is het ook te parsen met een XML-parser. Dat maakt het dan weer fijn voor andere applicaties...

[StefSybo]

Daar heb je geen XHTML voor nodig hoor, gewoon goede HTML hoort ook in alle browsers te werken (alhoewel je in IE natuurlijk grote kans hebt dat het niet werkt).

[JeRa]

Zo voorziet XForms in de mogelijkheid om client-side gegevensvalidatie uit te voeren...

...waaruit volgt dat designers vaker de serverside validatie links gaan laten liggen? Ik voorzie een hoop beveiligingsproblemen, of is er toch nog een vorm van beveiliging die dit soort ongein voorkomt?

[da Burp]

Dat ligt dan toch echt weer aan de ontwikkelaar. Je zal gewoon goed na moeten denken over welke validatie je eventueel persee serverside wil verrichten ivm veiligheid.

Ik kan echter genoeg dingen verzinnen die of je ze nou clientside of server side controleert niks afdoen aan de veiligheid. Mij lijkt het persoonlijk dan wel een handige mogelijkheid.
Maar als het niet breed ondersteund wordt is het enigzins zinloos om het te gebruiken. Dat zou betekenen dat je verschillende forms moet gaan maken omdat niet iedere browser XForms zou ondersteunen. Voor zover ik weet steekt MS weinig in de ontwikkelingen van IE op dit moment. Dus zolang het daar niet in zit is meteen een groot deel uitgesloten. Dus als Mozilla dit implementeerd is het wachten waarschijnlijk op MS voordat het breed gebruikt zal worden. Of je krijg straks allemaal pagina's waar staat "Deze pagina kan alleen worden gebruikt met Mozilla (Firefox)"

[Anoniem: 81430]

ik vind er niks op tegen om sites Firefox-only te maken. er zijn nu toch ook IE-only sites, waar linux gebruikers zowiezo niet op kunnen vanwege een of andere lui persoon die zich webmaster durft te noemen?

[StefSybo]

En daarom ga jij je ook maar verlagen tot het niveau van die "webmasters"?

Op zich is er niks mis mee als een pagina niet in een bepaalde browser geopend kan worden, maar dan wel omdat je een feature gebruikt die in de andere browser niet mogelijk is, en niet omdat je de gebruikers van die andere browser wil pesten of omdat je te lui ben om te controleren of je site in meerdere browsers werkt.

[Anoniem: 81430]

met als klein detail dat windows gebruikers zowel IE als Firefox kunnen gebruiken en linux gebruikers IE niet. IE-only sites zijn er alleen om non-windows users te pesten en dat gaat niet op voor FF-only sites.

En wat jij zei was ook wat ik bedoelde, maar vergeten was erbij te zetten omdat ik me liep op te winden over IE sites: dat je een feature in een pagina stopt die niet ondersteund wordt in IE is niet niet de schuld van de feature, maar van MS die hun browser niet meer doorontwikkeld.

[TheOneLLama]

Dit is bedoeld zodat je met dezelfde opmaak taal (XForms) zowel client side als serverside dezelfde validatie kan doen. Dit betekend dat de gebruiker, zelfs al tijdens het typen, een waarschuwing kan krijgen dat de invoer fout is. Vervolgens kun je op de server checker, met dezelfde XForms opmaak, of de data ook *echt* klopt.

Je hoeft dus niet en een PHP/ASP manier, en een Javascript/DHTML achtig iets te maken om de data te controlen. Bovendien is het duidelijker voor de user waar het bij iedere site nu op dezelfde manier gebeurt, niet dat iedere site een ander soort javascriptje gebruikt om te waarschuwen dat de invoer niet klopt, etc.

[jvo]

Inderdaad. De client-side verificatie heb ik eigenlijk altijd 'voor de lol' gedaan. Zodat de gebruiker geen rare foutmeldingen krijgt te zien. Server-side verificatie doet het eigenlijke werk en dat lijkt me altijd het veiligste.

[Sendy]

Deze XForms verificatie is ook alleen voor de lol. Je kan er bijvoorbeeld in zeggen dat een veld aan een bepaalde waarde moet voldoen en de actie die er moet gebeuren als je een verkeerde waarde invult (bijvoorbeeld een tekst displayen als "Dit moet een getal zijn".

[mxcreep]

Kan nu ook al prima met regular expressions in javascript...

[Sendy]

Dat klopt. Alleen heb je dan met XForms geen javascript meer nodig, en is het ook bruikbaar in allerlei (XML) toepassingen.

[Anoniem: 15143]

Je applicatie dient zo-ie-zo ALTIJD serverside de input te controleren. Iedereen kan namelijk html/xml aanpassen en daarmee eventuele clientside validaties te omzeilen.

Dat ziet altijd de input wordt gecontroleerd heeft regelmatig vulnerabilities tot gevolg. De meeste buffer overflows zijn het gevolg van het ontbreken van validatie. Dat niet elke functie zijn input controleerd heeft vaak te maken met een keuze op het gebied van performance.

Client validatie is een 'service' naar de bezoeker toe. Client side validatie mag nooit de taak van serversided validatie overnemen..

[CyberSnooP]

Ik ben benieuwd hoeveel gebruik er van deze implementatie gemaakt gaat worden. Er heerst namelijk de mening dat XForms lastig te gebruiken is voor webdesigners en moeilijk te implementeren is voor browser-fabrikanten. Zolang er geen brede ondersteuning is zul je het op publieke sites niet snel tegenkokmen verwacht ik.

Daarnaast is er nu alweer een andere web-applicatie-gerichte standaard in de maak door de WhatWG. namelijk Web Forms 2.0 (zie ook de relatie tussen WF2 en XForms).

De tijd zal leren wat we in de praktijk tegen gaan komen in de toekomst. Dat Mozilla opties openhoud en zichzelf als een nog sterker platform neerzet door deze standaard te implementeren is alleen maar positief.

[Anoniem: 34169]

Gelukkig is het nog altijd W3C die de internetstandaard bepaald, en niet een of ander vaag commercieël bedrijf.

[Anoniem: 105379]

[sarcasme] Inderdaad ! Zie o.a. de geweldig implementatie van onder andere Portable Network Graphics (PNG) in Microsoft Internet explorer ![/sarcasme]

[Anoniem: 57363]

Daar heb je inderdaad een punt. Dit zal alleen worden toegepast bij professionele implementaties. Ik zie dit een beetje als het 'GET' en 'POST' issue bij Forms. GET is onveilig(er) zou moeten verdwijnen, maar bestaat nog steeds.

[Anoniem: 104948]

get en post zijn identiek hetzelfde

het enige verschil zit hem in de plaats waar de data wordt gezet

bij de get komt die in de headers waar de andere dingen staat zoals content-type en daarom is de get gelimiteerd in lengte

de post komt onder de andere headers te staan en is vrijwel ongelimiteerd

dat is het verschil ...
GET moet blijven omdat je via links heel eenvoudig kunt werken bv. om een fotoboek te maken met pagina's enz enz ;-)

is even veilig of onveilig (wat je wil)

[Onno]

Is het niet zo dat POST bij een SSL verbinding versleuteld wordt en GET niet?

Nee. Alles, van begin tot einde, is beveiligd.

Get niet omdat het dan niet meer mogelijk is de URI op te vragen.

Eh. De webserver decrypt de gegevens natuurlijk eerst weer.. als de webserver zelf ook niks met je ge-encrypte gegevens kan heb je er nogal weinig aan.

[Anoniem: 45413]

Is het niet zo dat POST bij een SSL verbinding versleuteld wordt en GET niet? Get niet omdat het dan niet meer mogelijk is de URI op te vragen. Zodoende is POST geschikter om gevoelige informatie te versturen over een versleutelde verbinding, zoals creditcard gegevens en inlognamen en wachtwoorden.

[Anoniem: 32075]

Hrmm.. dat kunnen we natuurlijk effe checken met www.ethereal.com en kijken naar de dump. Doe ik straks als ik thuiskom want volgens maakt de GET niet noodzakelijk deel uit van de sessie.

[Onno]

volgens maakt de GET niet noodzakelijk deel uit van de sessie.

Een SSL sessie wordt altijd opgezet voordat er data verstuurd/ontvangen wordt. Alles is per definitie beveiligd.

Dus je kunt jezelf wat moeite besparen.

De enige reden dat GET als 'onveiliger' gezien wordt is dat request URI's vaak gelogd worden, en de content niet. Maar dat heeft niets met de encryptie te maken.

[Anoniem: 2198]

GET en POST zijn beiden even (on)veilig hoor. Dat een GET de variabelen direct via de URL meeneemt maakt echt niks uit

[spoonman]

>GET is onveilig(er) zou moeten verdwijnen

Veel succes met je dynamische website als je de gebruikers wil toelaten om bookmarks te maken (tenzij je het aanpakt zoals femme gedaan heeft met deze site)

GET is enkel "onveilig" als je het op een verkeerde plaats gebruikt, en echt zoveel veiliger is die POST niet hoor. Pagina op je desktop saven en action attribute aanpassen, wat hidden fields aanpassen en prullen maar (tenzij de webdeveloper van die site de tijd heeft genomen om er referer checks in te plaatsen)

[mxcreep]

Er is niks onveiligs aan GET en POST, je moet gewoon in alle gevallen een server side validatie uitvoeren op alle velden....
Client side controles zijn vaak fijn voor de bezoeker aangezien hij zonder een pagina reload al kan zien wat er wel of niet juist is ingevuld, maar nog steeds moet je de data server side valideren...ten eerste al om te controleren of er wel juiste data ingevoerd is en tevens om sql injections te voorkomen.

Wat een nadeel kan zijn van GET variabelen is dat ze uiteindelijk terug te vinden zijn in de webserver logs...maar goed de maker van de site kan zowieso alle data loggen die verstuurd wordt.

[Anoniem: 45413]

Ja inderdaad zeg, XPath en XML Schema zijn echt niet zo makkelijk. XHTML 2.0 is misschien onhaalbaar voor nieuwelingen zonder speciale software als Dreamweaver. Wel jammer, maar voor de implementatie hoef je denk ik niet bang te zijn. Alle fabrikanten willen naar standaarden toe, het duurt alleen wat lang bij sommigen.

[Anoniem: 2141]

De implementatie van XForms 1.0 is echter nog een flinke klus aangezien de standaard rust op andere XML-standaarden zoals XPath en XML Schema. Deze twee standaarden zullen eerst moeten worden geïmplementeerd door de ontwikkelaars van Mozilla teneinde XForms te kunnen ondersteunen.

hier zijn prima open source libraries voor

[ATS]

hier zijn prima open source libraries voor

Maar die moeten qua ontwerp (api, datatypes, etc.) natuurlijk wel goed passen in de rest van je systeem, anders kan je wel vergeten dat je een efficiënte implementatie krijgt.

[Genoil]

Als je IE6 hebt, kun je al een tijdje met een XForms implementatie spelen: http://www.formsplayer.com

Het is natuurlijk 'slechts' een browser-plugin, maar wel aardig om het alvast te leren begrijpen...

[Anoniem: 109985]

En wat heeft Microsoft gezegt over de implementatie hiervan? Als IE achterblijft zie ik het geen groot succes worden, iig niet snel.

[aaiding]

Je kan XForms straks ook gebruiken in SVG. (In de beta (/alpha) versie van Adobe SVG Viewer 6 is daarin al een aanzet gemaakt.

Da's dus wel ff superhandig... nu moet je met widget libraries werken e.d.

[JeromeB]

offtopic:
Sinds wanneer is XHTML 2.0 al een standaard? Volgensmij zijn ze nog steeds bezig met de working-draft. Kunnen we het dan al een standaard noemen?

Verder is het web natuurlijk nog niet toe aan XForms (WebForms is daarom een beter alternatief), maar de implentatie (in verschillende applicaties/browsers) is wel belangrijk om het ooit van de grond te krijgen.

[Ids Lupo]

http://www.w3.org/TR/2004/WD-xhtml2-20040722/
Het is nog een working draft....

[whitehouse]

geweldig !!

betekend dit dat je nu losse variabelen naar de server kunt sturen zonder dat de form in zijn geheel moet worden veerstuurd ?

[YoNiE]

je kan toch altijd al een form met 1 losse key:value sturen?

[pling]

En bij Microsoft werken ze aan XAML. En bij MacroMedia werken ze aan Flex.