Re: XForms Object Model discussion?

Hello,

In my opinion the modularisation of every possible tag that is defined in a
standard would be ideal to have an extendend API/OM to have a better
understanding of what's happening when different XML implementations are
programmatically invoked even if it doesn't add any functionality.

I think the XForms standard should also have a OM inherited from the XML
object model, like other standards as XHTML, SVG(!).

For example:

(XML DOM):

var row1 =
table1.childNodes.appendChild(table1.ownerDocument.createElement("tr"))
var row2 = table1.childNodes[1]

is more abstact than

(Possible XHTML DOM)
var row1 = table1.rows.add();
or
var row1 = table1.rows.add(table1.createRow());
or
var row2 = table1.rows[1]

even though it does exactly the same thing, it masks and alters the
underlying XML DOM to make it easier to read and only requires you to know
the object model.

But more important, it prevents mistakes like

var row1 =
table1.childNodes.appendChild(table1.ownerDocument.createElement("td"))

because a good compiler wouldn't even allow to create anything else than
rows, tablebody and tablehead under a table.

I haven't deeply studied the XForms principles, i know it allows much more
complicated relations between different XML Elements than can be used in the
XML DOM, so most HTML Enabled OO-languages will have similar inherited
objects developed for IDE's (.NET, Delphi 7 & Delphi.NET, Java, C++).

Without some kind of standard DOM in XForms, these objects will probably all
differ heavily in functionality and logic when they will be available in
IDEs.

I read that de declarative model would take away 80% of the scripting
requirements (according to Micah, thanks ;-) but ofcourse this is never
enough and people will always want to do the things that aren't possible
with the current model. (i'm usually one of them)

Providing a standard syntax/API (in wich you wouldn't alter the XML DOM but
the XForms DOM alters the XML DOM) would prevent a LOT of bad-programmed
websites/applications with tons of JavaScript/XForms parser errors.

[Conclusion (:-)]:
programmaticaly altering the XML Model to build/alter a XForm will always
cause more errors and gives less insight in code than altering a XForm
through an API.

Hope this explains it a bit why i would like to see an XFOM.

Thanks for Reading!

Luck to you all, Wiebe Tijsma

ps yes cybi don't worry my mother language is dutch so probably my english
is neither flawless and believe me, i've seen worse from people who do have
english as their mother language ;-)...

----- Original Message -----
From: "Cybernd" <cybernd@cybernd.at>
To: "Wiebe Tijsma" <wiebe@tijsma.com>
Sent: Thursday, May 30, 2002 3:54 PM
Subject: Re: XForms Object Model discussion?

> im trying to implement such object model for java ...
> but its only based on my ideas .. my mind .. because its hard to find
> peoples getting in touch with xforms ....
> and when there are some discussions inside xforms mail list .. these are
> always to specific and not really relevant for my work
>
> whats your intention when you search for some kind of Xforms OM?
> im writing those lib because i think its not the best way to write xforms
> into some kind of konfiguration file .. then parse it into your
applikation
> ...
> i think its better to have some kind of API which will hide all xforms
> specific details, so there should be no way to produce non valid xforms
> inside your applikation, maybe its also possible to write gui editors like
> current swing editors (netbeans .. jbuilder .. and so on) for xforms based
> on those OM ...
>
> cybi alias Neuhauser Bernhard
> ICQ uin 33535143
> (aja p.s. please forgive me for my bad written english ... german is my
> mother language and i truly lack english skills :)
>

Received on Monday, 3 June 2002 06:17:17 UTC