Page 1 of 1

XForms versus FORM libraries like OF_Forms/HTML_QuickForm...

Posted: Sat Oct 28, 2006 2:48 pm
by alex.barylski
So I read a bit more on xhtml 2.0...nothing really interesting...or maybe I'm just not interested yet...

XForms caught my eye...although I haven't searched anything on it...the idea that they are finally seperating FORM from HTML is intriguing(sp?) :)

OsisForms and HTML_QuickForms are slowly beginning to appeal to me...for the longest time I disliked the idea, because of the lack of *absolute* control using tables, but the more comfortable I become with CSS...the more I can see myself using something of that nature...

So I get (from a conceptual level) how FORM classes work, in that you manipulate an API and it generates the HTML for you...

But with little knowledge of XForms outside of them being for XHTML 2.0 (ignore my inaccuracies if I am wrong here please) what I want to know is...

Can someone explain the fundemental and conceptual differences between XForms and how they will replace or work with FORM classes like those mentioned above?

Cheers :)

Posted: Mon Oct 30, 2006 3:09 pm
by Ollie Saunders
Good thing I spotted this thread eh? :)
OsisForms and HTML_QuickForms are slowly beginning to appeal to me...for the longest time I disliked the idea, because of the lack of *absolute* control using tables, but the more comfortable I become with CSS...the more I can see myself using something of that nature...
This is something I've been working on today actually. The render methods on any entity will accept a parameter telling it what parts you want to render. Every entity has a header, content and footer. So you can do something like this:

Code: Select all

$field = $factory->text('field', 'Foo:');
$anotherField = $factory->text('anotherField', 'Bar:');
?>
<table>
 <tr>
  <td>
   <?php $field->render(OF::CONTENT); /* renders just the field itself */?>
  </td>
 </tr>
</table>
<?php
// OF::ALL == OF::HEADER | OF::CONTENT | OF::FOOTER
$anotherField->render(OF::ALL)
$field->render(OF::CONTENT) outputs

Code: Select all

<label for="field">Foo:</label><input type="text" id="field" name="field" value="" />
$anotherField->render(OF::ALL) outputs:

Code: Select all

<div class="field"><label for="anotherField">Bar:</label><input type="text" id="anotherField" name="anotherField" value="" /></div>
By default entities in containers output on top of one another but you will be able to use a tabular container (row method from the factory) to make entities appear side by side. So you'll mostly never need to do that stuff ^^ with HTML.

I've been reluctant to release this but go on seeing as the release date for OsisForms is officially 7th of December...here's the early documentation for my library. (Only available when I have my server on).

As for XForms, it is entirely dependent on the uptake of browsers...so everything is on hold really. You can get an extension for FireFox for it but, of course, until IE implements it nobody is really going to be able to use it. Of course with OsisForms brand spanking new OO design you can now write separate renderers (output) and retrievers (input) for it so some time in the future you'll be able to migrate your old HTML forms to XForms by changing a single line -- at least that's the idea.

Posted: Mon Oct 30, 2006 3:28 pm
by Weirdan
You can get an extension for FireFox for it but, of course, until IE implements it nobody is really going to be able to use it.
There's plugin for IE as well.

Posted: Wed Nov 01, 2006 7:07 pm
by avernet
You can also install something on the server side, which will transform your XForms into HTML and run the form using Ajax. So no need to have a plug-in or Firefox extension in place.

One solution that does this is the open source Orbeon Forms. See the screencast here:
http://www.orbeon.com/software/screenca ... amples-640

And there are a few online demos linked from:
http://www.orbeon.com/software/get-excited

From there you can also download the bits, if you want to play with it. It runs on Java/Tomcat, so integration with PHP might or might not be an issue for you.

Alex

Posted: Thu Nov 02, 2006 3:55 am
by Ollie Saunders
As long as these things aren't bundled with the browser there is always going to be the issue of "take-up".

Posted: Thu Nov 02, 2006 11:39 am
by avernet
ole wrote:As long as these things aren't bundled with the browser there is always going to be the issue of "take-up".
If you can run XForms on the server-side, the process is transparent for the programmer and the end-user. It's a little bit like XSLT: if you can run XSLT on the server-side, you don't have to worry about the client supporting XSLT in the browser. And this is now what all the sites that use XSLT (like eBay) are doing. BTW, on the issue of running XForms on the server-side, see this FAQ entry:

http://www.orbeon.com/ops/doc/home-faq#xforms-browsers

Alex

Posted: Fri Nov 03, 2006 4:17 am
by Ollie Saunders
OK this is amazing: http://www.orbeon.com/software/screenca ... amples-640
This is definitely the direction I want to head in with my library.

The software being demonstrated in that video uses OPS
OPS requirements wrote: To install OPS you need an application server that runs on Java version 1.4.2 (or later) and implements the Servlet API 2.3 (or later). OPS has been tested on the following application servers:

* Apache Tomcat 5.5.20 (JDK 1.5.0)
* BEA WebLogic Server 9.1 (JRockit)
* IBM WebSphere 6
* JOnAS 4.6.6 (Tomcat 5.5.12, JDK 1.5.0)
* JBoss 4.0.4

Posted: Fri Nov 03, 2006 11:33 am
by alex.barylski
Interesting...

Although that OPS uses XML to store the data and claims to not use any AJAX/DHTML...so I assume this is where a browser would *need* to support XForms...otherwise I cannot see how the DOM is manipulated...???

So your idea is to replicate that functionality, but using AJAX as a fallback on browsers which do not support XForms natively or with plugins???

Posted: Fri Nov 03, 2006 12:32 pm
by avernet
Hockey wrote:Interesting...

Although that OPS uses XML to store the data and claims to not use any AJAX/DHTML...so I assume this is where a browser would *need* to support XForms...otherwise I cannot see how the DOM is manipulated...???
This is the idea:

1. You as a developer write XForms
2. You put the XForms file on the server
3. The end user makes a request to the server with his browser (without any plugin)
4. The server (where Orbeon is installed) transforms your XForms in HTML + Ajax that the browser understands
5. The end user gets the form in his browser and can interact with this rich form..

This is really to enable the use of XForms without requiring any plugin to be installed on the browser.
Does this make any sense? :)

Alex

Posted: Fri Nov 03, 2006 6:40 pm
by alex.barylski
Thats basically the understanding I had...thank you for clarifying :P

p.s-Excellent name ;)

Posted: Sat Nov 04, 2006 3:37 am
by Ollie Saunders
So now the next thing to do is to port it to PHP :P