New browser-based XForms processor

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

New browser-based XForms processor

claud108
Hi,

I have started to develop a new browser-based XForms processor, which will make use of browsers' native XPath and XSLT capabilities.
Thus, the approach is as follows:
- transforming XForms page into XHTML + JS page by using XSLT in browser (Alain Couthures' very good idea);
- storing instance data as XML within the page;
- bounding this data to UI controls by using browsers' document.evaluate() function (except IE, which is a rara avis, and will be dealt with later);
Claudius Teodorescu
http://kuberam.ro


Reply | Threaded
Open this post in threaded view
|

Re: New browser-based XForms processor

Alexander Žaťko
Hi Claudius,

Could you please explain how is your project different from XSLTForms? I am asking because the Xforms landscape is littered with unfinished and often abandoned, once-promising projects, and I wonder why not to contribute your ideas and programming skills to an existing effort instead of starting a new one?

Alex.

On May 27, 2010, at 2:23 AM, Claudius Teodorescu wrote:

Hi,

I have started to develop a new browser-based XForms processor, which will make use of browsers' native XPath and XSLT capabilities.
Thus, the approach is as follows:
- transforming XForms page into XHTML + JS page by using XSLT in browser (Alain Couthures' very good idea);
- storing instance data as XML within the page;
- bounding this data to UI controls by using browsers' document.evaluate() function (except IE, which is a rara avis, and will be dealt with later);
Claudius Teodorescu
http://kuberam.ro




Reply | Threaded
Open this post in threaded view
|

Re: New browser-based XForms processor

Alain COUTHURES
In reply to this post by claud108
Hi Claudius,

For performance increasing, especially because of IE slowness,  I'm also considering XML data islands to be used by XSLTForms instead of Javascript objects. Those Javascript objects are now also used to store meta data whether the corresponding node (which might be an attribute) is valid, read-only, associated with an XML Schema type and so on. That's why instance data would have to be expanded with extra attributes and attributes would have to be stored as elements! XSLT might then help for expanding and serializing.

Using native XPath is also an interesting idea for reducing Javascript number of instructions about all those meta data. Unfortunately, native XPath is just XPath 1.0. XForms recommendation defines very useful extra XPath functions and, probably XPath 2.0 will be considered for next recommendation. Those functions are mandatory for effective web applications without Javascript instructions. That's why XSLTForms will keep its own XPath engine for evaluating "XForms" XPath expressions. There is another important reason for this: when performing an XPath evaluation, XSLTForms collects dependencies and I don't know how this could be done in a different manner.

I will look at your new project with great interest.

-Alain
Hi,

I have started to develop a new browser-based XForms processor, which will make use of browsers' native XPath and XSLT capabilities.
Thus, the approach is as follows:
- transforming XForms page into XHTML + JS page by using XSLT in browser (Alain Couthures' very good idea);
- storing instance data as XML within the page;
- bounding this data to UI controls by using browsers' document.evaluate() function (except IE, which is a rara avis, and will be dealt with later);
Claudius Teodorescu
http://kuberam.ro



Reply | Threaded
Open this post in threaded view
|

Re: New browser-based XForms processor

claud108
In reply to this post by claud108
The processor I working on, called kuberaForms, already passed 200 of the XForms test suites.