- From: Plechsmid Martin <Martin.Plechsmid@merlin.cz>
- Date: Thu, 25 Apr 2002 14:16:34 +0200
- To: "'Piroumian Konstantin'" <KPiroumian@protek.com>, Plechsmid Martin <Martin.Plechsmid@merlin.cz>, "'XForms'" <www-forms@w3.org>
- Cc: "'ivelin@apache.org'" <ivelin@apache.org>, "'tcurdt@apache.org'" <tcurdt@apache.org>
> If I get it right, you are using JavaScript and IE features > to create the > instance data that is posted to the server using a hidden > input field on a > form? Yes. I think that other browsers have analogous features that can be used for the same purpose, but we haven't tried to port our software there. > Are you using IE DOM model as well? Yes, it is necessary if you are to support the <xforms:repeat> element, for instance. > How do you handle XPath expressions? We require the MSXML 3.0 parser installed. This parser supports xpath expressions searching. The xforms extensions to xpath are handled via transformations to javascript using regular expressions. That is, xpath strings are transformed into a combination of xpath searches and javascript. > Anyway, you'll end up with a very complicated JavaScript. Mozilla's JS lib > is about 60K monster (and as I know it's only the 75% of XForms spec). And our is even bigger :-). But I think we support more than 75% (I would say most of it, but I don't dare to guess how much). > This is the result of XForms spec beeing very client oriented. I think that > Cocoon's solution moves in the right direction and it's more server > oriented, although implementing most of the cool XForms features will > require also a lot of client side programming. I haven't looked at the Cocoon project yet, but I cannot imagine how you could shift the functionality we implement in javascript from client to server. Moreover, if you have a havy loaded server, you cannot waste capacity by helping client computers and computing what the clients are able to do themselves. Martin.
Received on Thursday, 25 April 2002 08:17:20 UTC