Posts tagged ‘client-side’

What’s new in betterFORM limegreen


Release Notes

These are the release notes for  betterFORM limeGreen (4.0).

New features

Event Log

In previous versions of betterFORM event logging was available on the Firebug console (or its respective counterparts in Chrome and Safari). However this worked only for the uncompressed version of betterFORM as it relied on the console.debug feature of those tools.

In betterFORM limeGreen 4.0 there is a new event log that helps tracking the events exchanged between browser and XForms processor on the server regardless of the mode of operation. It is enabled by configuring the debug option in betterform-config.xml like this:

<property name="betterform.debug-allowed" value="true" description="if true enables debug bar and event log viewer"/>

When active there will be a small icon in the upper right of the browser window. Clicking on that will reveal the event log.

In the event log each event that is received from the server will be listed with all of its context information. In some cases where an targetElement or targetId is given you can click on a link and the respective element in the browser will be highlighted in blue.

The icon in the upper right will allow to expand or collapse the event log while the trash bin icon allows to remove all entries from the log.

 

 

 

 

 

 

Error Highlighting

One of the most common errors when authoring forms is to produce a xforms-binding-exception. In complex forms these can be hard to locate. The new error highlighting feature improves this by giving you the exact line in your markup where your binding exception occurs.

Sample image illustrating the error highlighting feature

In addition to the markup the requested URL and the exact XPath for the problematic element is shown.

Syntax Highlighting for Host and Instance Documents

The debug bar has been enhanced to now show the host and instance documents syntax highlighted too. Here’s an example:

sample of syntax highlighted host document

Configurable Position for Ephemeral Messages

betterFORM uses a Dojox toaster control for displaying ephemeral message. These were always shown at the bottom of the screen. The position for these messages is now configurable by adding an attribute to the root node of the document:

<html xmlns=”http://www.w3.org/1999/xhtml&#8221;
xmlns:xf=”http://www.w3.org/2002/xforms&#8221;
xmlns:ev=”http://www.w3.org/2001/xml-events&#8221;
xmlns:bf=”http://betterform.sourceforge.net/xforms&#8221;
bf:toaster-position=”tl-down”>

The toaster position now can be any of the four corners of the browser window. Valid values for the attribute ‘bf:toaster-position’ are documented in the Dojo docs.

Automated Web Tests

Not strictly a new feature but we have started to automate cross-browser testing by using the new Selenium webdriver. We have already implemented a lot of tests which are now run twice a day to reveal potential regression bugs. The test assertions will be expressed in an XML format to ease the implementation of tests. From these definitions the Java code for Selenium will be generated. The tests may then be run against different browsers. We will continue to add tests and probably make the testing infrastructure available for developers that like to do their own tests.

Moved to Less for CSS Styling

LESS has a growing popularity for doing complex CSS layouts. Check out their website for an overview of the features. We decided to move all relevant CSS stylesheets to LESS as it is much more expressive than CSS and e.g. allows variables to avoid redundancies. LESS files get compiled into standard CSS so there are new dependencies at runtime nor restrictions on the use of ‘normal’ CSS files.

XForms Editor Preview (RC 2)

Starting with RC 2 there will be a new XForms editor in betterFORM. It will be (not in the first place) wysiwyg page editor but a pure XForms 1.1 editor which allows to edit all XForms markup contained in some (X)HTML document. It focusses on the abstract view of XForms authoring and assists to keep your markup clean and consistent. Large parts of the editor are generated directly from the XForms 1.1 schema thus supporting the full set of XForms elements and attributes plus the XML Events schema.

The first version will give access to the complete XForms language vocabulary unfiltered and will mainly target more experienced XForms authors. Starting from there ‘profiles’ will allow to filter and change the representation of the attribute editors and add authoring convenience functions.

After ‘expert mode’ (above) a ‘basic mode’ is planned as an alternative view for non-XForms users. This will works with implicit instances (instance nodes created on the fly) and smart defaults for quick editing without all the rarely used features.

What’s already working:

  • parsing of any XHTML/XForms document and opening it in the editor. Only XForms markup will be shown.
  • expandable/collapsible (tree-like) view of the XForms markup
  • schema-aware sidebar that shows only possible children and siblings for a given element
  • schema-aware dnd – still a bit quirky but allows to move elements in the tree
  • schema-aware moving of elements by keyboard shortcut (this works really nice)
  • ‘attribute panes’ with all possible attributes of a given XForms element which update the markup tree
  • inserting and deleting of all XForms elements
  • serializing changes
  • applying changes to original input document
  • preview, save + save as

We hope to create a tool for XForms authors to create fully valid XForms documents and appreciate all comments and suggestions. Contributors welcome.

ProjectAssistant

To simplify the setup of projects using betterFORM XRX there’s a new helper build tool called ‘ProjectAssistant’. It helps to keep your project sources separate from the betterFORM sources while still giving access to the full functionality of the complete source tree. It also allows to easily switch to a newer version of betterFORM as soon as it becomes available.

Google App Engine (RC 2) (revised)

betterFORM can now be deployed on Google App Engine and thus be run in the cloud.

There are still some detail issues to be solved to actually make it happen. We’ll continue to work on that.

Work on this has been stopped due to lack of resources and seemingly lack of interest. If someone likes this to become part of betterFORM please speak up on the mailing-list.

Windows Installer (RC 3)

There is a new Windows installer packaged as an .exe file to make installation for Windows users even easier.

Single-jar deployment (RC 2)

Starting with Release Candidate 2 betterFORM will default to using a single-jar deployment. This means that all Java classes plus all the needed resources  (CSS, js, image and xsl files) will be packaged in a single-jar file that can easily be added to a web application. The jar will contain an optimized version of the JavaScript used in betterFORM and the overall size of the archive will be about 2.7 megs.

A new resource handler allows to turn caching on and off.

betterFORM XRX extension for eXist

We are very happy to announce that we now have a tight cooperation with the eXist project and directly commit the XRX extension to the eXist trunk. However we will continue to offer our own eXist/betterFORM bundle as a ready-made installer packed with the latest stable version of eXist.

One hotspot of our activities was to refine the eXist integration and to fix the issues that existed in the former release. There were some inconsistencies and shortcomings of that release and we think we have finally sorted those out. Configuration and installation should now be smooth.

We also concentrated on making the betterFORM extension a good starting point for building XRX applications that are stored completely in the database. There also will be a browsing tool that lets you browse, execute and view the sources of all of your app files. Additionally you can upload files to the database and create new collections as needed.

Dashboard

The betterFORM Dashboard is the new starting point when working with betterFORM. It replaces the simple form.jsp of former versions and allows to mange your XForms documents along with their resources (CSS, images, static HTML, JavaScript) in one place. Dashboard works on both pure webapps with filesystem storage or as collection browser for a XRX application on eXistDB.

betterFORM dashboard

Dashboard supports the XML application developer and XForms author in working with their resources. It lets you browse the hierarchical structure of your applications, create new collections, upload files and view the source-code. It will also allow to start the XForms editor with an additional button.

Dojo Upgrade (revised again)

Dojo 1.5 is now integrated. All Dojo themes (tundra, soria, nihil and claro) can now be used in the forms. While we are working on the release a new release (1.6) has become available. We’ll upgrade before final release.

The Dojo Foundation has released version 1.6 while we were working on our release. We have upgraded to that version without issues so now Dojo 1.6.1 will be part of limeGreen and allows to use the latest and greatest of Dojo.

Dojo 1.7 is already on the horizon (first betas are out). We’ll probably upgrade again if it becomes final before betterFORM limeGreen final is released.

Finer grained Dojo builds

There are finer grained Dojo profiles now for building optimized JavaScript files to reduce the size and amount of downloaded resources. Besides a minimal, medium and full profile it’s now also possible to build optimized JavaScript files for a specific page.

Attribute Value Tempate (AVT) support

AVTs are now fully supported on foreign elements (typically HTML). That means you can use XPath expression in any HTML attribute for instance class=”{foo/bar}” will evaluate the XPath according to the XForms in-scope context rules allowing you to manipulate the rendering of HTML from XForms.

New Submission modes

There are two new submission modes:

  • a submission @replace=”embedHTML” now allows to embed HTML markup in your current document. You typically might want to use that to call some URL that produces HTML markup by templating  (e.g. long output tables to display data). HTML can also be embedded by using a xf:load action but a submission gives you finer-grained control of your request (sending data if needed, validated or not, setting headers, error-handling etc.)
  • a submission @replace=”new” allows to open the result of a submission in a new window. Please note that this functionality has been accepted by the XForms WG as a new feature though with a different syntax. We’ll adapt to that syntax in a later release. Typical use case is the display of printable views.

XPath Functions

The Java classes implementing the XPath functions for XForms have substantially been refactored for easier extensibility. This is an important preparation for allowing users again to configure a new Java function library.

dispatch action supports custom contextinfo

The dispatch action now can take custom contextinfo. This is useful in context with subforms when single values shall be exchanged between models. An example illustrates that best. Assuming the action below is in scope of model A it may send either a static value or a pointer to an instance node value to model B with:

<xf:dispatch name="customEvent" targetid="foo">
    <xf:contextinfo name="param1" value="'hello'"/>
    <xf:contextinfo name="param2" value="value"/>
</xf:dispatch>

<group model="B" id="foo">
    <xf:action ev:event="customEvent">
        <xf:setvalue ref="staticResult" value="event('param1')"/>
        <xf:setvalue ref="xpathResult" value="event('param2')"/>
    </xf:action>
...

Context connector

There is a new connector with the scheme ‘context:’ that allows to store an instance into a hashmap of the XForms processor. This is a handy feature when composing wizard-style forms that are made of subforms and need to pass instance data back and forth. As the same XForms processor instance will be used over the live-time of the embedding document this can act as a global data-container for subforms.

SSL handling

SSL handling has been refined allowing a pluggable SocketFactory to be used. Details of the keystore can be configured in betterform-config and a howto has been added to the docs.

Multiple Labels

A control now may have multiple labels for different languages. This gives an easy alternative for quickly internationalizing forms. It’s planned to extend that approach for alerts.

Modal messages

Model message are now rendered as Dojo dialogs and fit into the respective Dojo theme that is used.

This change needed to be rolled back as there were problems in some rare conditions with the handling of focus events.

Event reduction

The amount of events propagated to the client have been reduced dramatically. From now on only events that really have been used in a form will be propagated over the net.

XForms Inspector (revised)

There already was a feature allowing to view XForms instances at runtime in a Firebug console. But the solution had some shortcomings:

  • you needed to run on Firefox with Firebug plugin to see the instances
  • it was not obvious to users that you had to add a ‘?debug’ to the form URI to get the buttons
  • and worst it did not show the instances of embedded models as these could change at runtime

The new solution still requires that you activate the ‘debug’ feature in the betterform-config.xml but is now independent of Firefox and Firebug. Once activated a bar is rendered at the bottom containing one link to see the host DOM as it exists on the server (pre-transform) as well as one link for each instance in each model. The links update if a model becomes available by embedding or is removed from the document by unloading.

The XForms inspector can now be collapsed to an icon to avoid hiding elements on the page.

XForms Dialog

we now implement the proposal for the dialog element along with its show and hide actions.

XFormsPostServlet

There is a new XFormsPostServlet to allow initialization of a XForms from a http POST containing xforms markup in the body.

XForms Feature Explorer / Reference

The XForms Feature Explorer serves as a live reference for XForms and betterFORM. It has been completely overhauled and given a clean structure with description (with spec links), live example and source code. Alongside of that you will see which CSS classes that apply in the respective context and can even see them at work when hovering the class name. New sample forms have been added beyond the basic control and container documentation.

Here is a screenshot of one reference form:

Screenshot of one reference form

Automatic CSS import for subforms

CSS style rules that are present in a document that is embedded will now get imported into the embedding document. Currently only style elements are handled but this still allows usage of external CSS files by using the @import instruction.

Automatic JavaScript import for subforms (RC 2)

Similar to CSS resources JavaScript blocks and linked JavaScript files from the head of the embedded document can be imported in the embedding document.

Refined user agent configuration

The betterform-config.xml now allows to configure a new user agent along with its supporting Java class and a XSLT transform.

Resource pathes

The handling of resource pathes has been simplified. Instead of having multiple pathes for CSS, scripts etc. there’s now only one for the resource root dir which is configurable in betterform-config.xml.

Saxon upgrade

The XPath processor is now using Saxon 9.2.1.5.

Http Client update (RC2)

The http client has been upgraded to latest version of HttpComponents (formely Apache Commons HttpClient).

Logging

Java code level logging has been refined in many areas now giving you more fine-grained control on the level of detail you’d like to log. Instead of just ‘debug’ we are now making use of the ‘trace’ level which produces much better readable output.

Configurable delay for incremental

Each control may now have an additional delay for the firing of incremental events. If delay is 0 there will be one event for each keypress while a control has focus. A bigger value will defer the firing for the specified time in milliseconds.

Refined alerts and hints

The default behavior for alerts and hints has been reworked. As the default now inline alerts and hints will be used. Hints will show when a control gets focus. Whenever a control gets invalid the alert will show in the same place as the hint (covering it). Alerts can be closed by clicking on them in case they cover other fields in a complex layout. The CSS for these child elements has been stabilized and works with horizontal and vertical layouts.

New alternative date control

There’s a new date control consisting of three dropdown controls instead of the datepicker popup.

Restructured XSLT transforms (RC 2)

The XSLT stylesheets responsible for the transformation from XForms to HTML have been completely overhauled for easier maintainability and extensibility. The base stylesheet now again produces native controls which can be overwritten to add functionality like scripting. As a result the overall stylesheets are more modular, smaller and easier to enhance.

Fixed Issues

  • fixed various problems with stale UI Events leading to repeating alert messages in the browser
  • an issue with downloading of schemas from the internet has been fixed (Ticket #40)
  • a hard-to-catch race condition with the ajax calls was fixed that only shows under heavy test conditions. Now the client-side uses a fifo buffer to make sure all events are processed in right order and even is able to discard events that may have become irrelevant in the meantime through network delays.
  • the style attribute was not handled correctly in all places. This is fixed now. (Ticket #28)
  • some issues regarding focus events (especially group and repeat focus events) have been addressed.
  • fixed naming inconsistencies of betterFORM CSS classes (Ticket #26)
  • fixed a problem with loosing trailing zeros during localization
  • Issue with betterform-index-changed events fix (Ticket #74)
  • fixed trailing zero problem for internationaized values (Ticket #73)
  • added missing xfValue class to triggers (Ticket #19)
  • fixed missing xforms-in-range event for select control (Ticket #48)
  • clarified issue with potential CSRF attacks in Tomcat 7 (Ticket #30)
  • clarified issue with Weblogic 10.3 (Ticket #81)
  • fixed broken Rating control (Ticket #39)
  • fixed problem with alert in secret elements (Ticket #66)
  • fixed problem with sum() function working on invaid nodes (Ticket #61)
  • fixed issue when ehcache is not configured properly (Ticket #103)
  • re-introduced xfRequiredEmpty class that signals required but empty fields after a submission error (Ticket #110)
  • slider problems in IE9 have been fixed (Ticket #140)
  • a problem with large localised decimals has been fixed (Ticket #150)
  • a problem with setting of context params has been fixed (Ticket #139)
  • plus several dozens of minor changes
  • a problem with the context() function has been fixed (Ticket #29)
  • a problem with the validation on long decimals has been fixed (Ticket #150)
  • handling of upload in eXist integration has been fixed (Ticket #133)
  • a problem with ‘selection=open’ has been fixed (Ticket #116)
  • broken DOMFocusIn handling has been fixed (Ticket #156)
  • @value on Element value not working was fixed (Ticket #42)
  • SSL now may use Java provided keystone (Ticket #154)
  • event() function not evaluating has been fixed (Ticket #146)
  • namespace in submitted instance now behave spec-conformant (Ticket #130)
  • selection=”open” in repeats now works correctly (Ticket #157)
  • enhanced / fixed handling of HTTP headers
  • fixed problem with setfocus action not setting the focus in some situations
  • enhanced error information for exceptions
  • upgraded to Xerces 2.11
  • fixed problem with JavaScript in model actions (Ticket #203)
  • fixed ranges within repeats (Ticket #201)
  • fixed missing support for choice labels (Ticket #195)
  • fixed problem with dependant lists in IE8 (Ticket #192)
  • fixed escaping problem with entities (Ticket #193)
  • fixed problem with params on instance @src attributes (Ticket #189)
  • fixed bug with positioning of tooltip alerts (Ticket #198)
  • added a TimePicker implementation (Ticket #178)
  • fixed issue with html default namespace
Besides the above dozens of smaller issues have been addressed. For a detailed list please visit https://betterform.de/trac/query?status=closed&milestone=limeGreen+RC4&group=status&order=priority or check the commit history on Github.
Advertisements

January 20, 2011 at 9:00 pm 1 comment

Why client-side XForms is not enough


About 10 years after the first version of HTML the W3C felt is was about time to create a sucessor of the HTML forms. XForms as a new open standard was born. Back then it was not surprising that XForms was emphasized to be a client-side technology which was expected to be built into the browser just like HTML forms are (this attitude changed later during the further evolution of this standard ). But XForms is not comparable to HTML forms in many ways. While HTML forms only provided some controls XForms offers a complete processing model with an MVC architecture, events, actions and a submission module and more. Without going into the details about these differences this article focusses on one aspect which is surely a prominent one for a forms framework: validation.

While some garbage data may not be a problem for a guestbook they are for a serious web application. XForms as the new standard in this area comes to the rescue. It offers a declarative way to put fine-grained constraints on data and even define dependencies between different data items. Now XForms is not natively supported in a single browser on this planet. No problem as there are several good client-side implementations around to fill that gap. So choose one of them, define your constraints and the problem is solved.

But stop – wasn’t there something?

“Never Rely on Client-Side Data Validation

Client-side validation can always be bypassed.
Server-side code should perform its own validation. What if an attacker bypasses your client, or shuts off your client-side script routines, for example, by disabling JavaScript?
Use client-side validation to help reduce the number of round trips to the server but do not rely on it for security.”

This is a cite from the OWASP (Open Web Application Security Project) site – an organisation dedicated to improving the security of applications. But maybe those guys do not know XForms already? It has a rich and fine-grained processing model that makes sure that all data stay in a consistent state and are only submitted when validation runs green. The problem here is that most of the implementations are implemented in JavaScript which can be easily bypassed if a attacker wants to and at the same time provides the toolset needed to inject malicious code into the browser.

This seems to be exactly the argument that the opposers of XForms always proclaimed: as long as XForms is not natively supported by all major browsers it will never gain importance for web application development. But that’s a fake argument. Even if browsers would support XForms natively this would probably make it harder to build an attack but you can still setup a page that sends manipulated data to the submission target. So OWASP seems to be right: ‘never rely on client-side data validation’.

How to get out of this dilemma? Is XForms altogether a bad idea? The answer is definitely no. XForms provides exactly the functionality that is needed to build reliable, flexible and future-proof applications today. It will be there for years while proprietary solutions come and go at will of their vendors. And the problem does not only apply to XForms but to any client-side technology used for data entry.

So only use server-side implementations and avoid the problem? That can be an answer and in fact those implementations have proven in many projects that server-side XForms is a real option.  But server-side implementations are harder to setup and handle as the client-side ones. This raises the entry hurdles for many people. Further client-side implementations can be more responsive in some cases as they avoid roundtrips to the server that are otherwise mandatory for a full support of the XForms processing model.

How can this gap be overcome? We can go for a client-side XForms processor and replicate all validations on the server. This would of course take away much of the beauty of the declarative validation model of XForms as it forces to re-implement all validations on the server-side. And as XForms validation is so powerful it might even become a tedious, repetitive and sometimes hard to solve task. A lot of the productivity gain of XForms compared to hand-crafted script solutions would be taken away.

But the solution can be easier and more elegant. As XForms is an open standard all implementations should be interoperable meaning that the validation in one processor will lead to the same results as those from another. They are interchangeable. If we need double validation to really build secure web applications why not use a client-side processor to gather and validate the data and then send those data to a server-side processor for re-validation? All that would be needed is a reference to the original form document and the instance(s) in question. The server-side processor can then initialize the form with those instance(s) (which will include validation of the data) and forward the data to its intended URI. Or if something goes wrong send a response to the client that reports the problems found. The server-side processor would never create a UI or fire initialization events nor would it trigger any of the submission event handlers. Instead it would just forward the data or create a generic XML structure describing the validation errors.

However to make this idea a reality there are still some steps to take. An interface for the processor communication needs to be defined as well as a protocol for reporting and handling the errors. Ideally this protocol would become a part of the XForms standard itself. On the other hand XForms already has a powerful submission module that could be extended to address the described problem. E.g. a specialized URI scheme or additional property for the XForms submission element would allow to use a server-side processor to act as a proxy for a submission target.

Handling errors is a bit more complex and involves to develop a generic error-reporting structure (ideally expressed in XML) that can be interpreted by the client-side processor and results in alerts popping up or a general message explaining why submission has failed. As XForms is not most often not the only technology used to build a site or web application the using applications can also profit from such a generic error reporting by integrating it into their error page templates in cases where there is not a simple validation problem but a fatal condition that prevents a successful submission.

XForms is an open and device-independent standard and as such there will be hardly one implementation fitting all use cases and scenarios. But bridging the gaps between different implementations and let them act as one can underline the fact that open standards can accomplish much more than any proprietary solution will ever can.

August 26, 2010 at 1:55 pm 13 comments

JavaScript in betterFORM


Using JavaScript with XForms

Before diving into the details of how to use JavaScript with XForms (and specifically betterFORM) it’s worthwhile to think about why you might want to use it. Isn’t it one of the most often mentioned arguments that XForm makes writing JavaScript superfluous? The authors of the XForms spec. have been more cautious by stating:

“(…)reduces the need for scripting”

This clearly says that scripting might and most likely will be needed to build full applications. XForms is not the answer to all application needs. It is a domain-specific language especially designed for the purpose of form processing. It does this job extraordinary good and offers a rich set of features like strong typing, calculations and validations, dependency tracking, a powerful submission module, actions and event processing etc. etc. It has a MVC architecture and an abstract UI. The resulting forms are device-independent and can be run or ported to other XForms implementations as it’s an open standard.

So we know why we have decided for XForms but why should we want to use JavaScript?

When you write XForms you typically don’t need to worry about writing JavaScript for processing your forms. XForms gives you all functionality to do so in a declarative way. But you need more than ‘just’ forms when you want to build complete applications:

  • you will need some layout facility like CSS to render your forms nicely
  • you may want subforms that communicate with each other
  • you’ll likely want a nice AJAXified user interface that update only parts of the screen
  • you will want to have your forms modularized instead of monolithic
  • you may want to interact with the browser directly by hooking into browser-events or manipulating CSS classes
  • you may want to integrate a ‘foreign’ component and let it speak to the XForms processor

As a domain-specific language XForms needs to integrate with the host language to cover the last mile from abstract UI to a concrete rendering on a specific device. XForms defines an IDL interface which can be used by the host. It does not offer much yet besides getting a model, an instance and call the rebuild, recalculate, revalidate and refresh methods. It’s quite likely that this interface will be extended in future versions of XForms.

#include "dom.idl"

   pragma prefix "w3c.org"

   module xforms {
      interface XFormsModelElement : dom::Element {
         dom::Document getInstanceDocument(in dom::DOMString instanceID)
            raises(dom::DOMException);
         void rebuild();
         void recalculate();
         void revalidate();
         void refresh();
      };
   };

betterFORM supports this interface and has an implementing class. More on that later.

In the meantime the XForms implementers have developed their own (vendor-specific) approaches to deal with the situation and allow the execution of JavaScript from XForms and vice versa.

The following section gives an overview over the JavaScript API of betterFORM.

The betterFORM JavaScript API – from JavaScript to XForms

When you are running an XHTML/XForms document with betterFORM your browser will get a HTML/JavaScript representation of the original document. This will contain all required script imports for working with the API . No further special preparations are needed.

betterFORM uses the Dojo toolkit for its client-side JavaScript layer. Dojo also allows declarative programming to create JavaScript components. When you look at the source view of your browser when rendering an XForms with betterFORM you will notice the following lines (formatted here for readability):

<div dojotype="betterform.FluxProcessor" jsId="fluxProcessor" id="fluxProcessor" sessionkey="1276614396436" contextroot="/betterform">
<div class="xfModel" style="display:none" id="model1" jsId="model1" dojoType="betterform.XFormsModelElement"></div>
...

The first div creates an instance of FluxProcessor. FluxProcessor is a Proxy for the actual processor at server-side and when calling XForms from JavaScript you will normally use one of its functions. Notice the attribute ‘jsId’. This establishes a global JavaScript variable that allows easy access to the processor. To call one of the functions of FluxProcessor you simply prepend it to the function name e.g.:

fluxProcessor.dispatch("myId");

The second div is a placeholder for the model in your XForms and implements the IDL interface mentioned above. There will be one instance of XFormsModelElement for each model in the XForms document. Same here –  you can reference the JavaScript XFormsModelElement via its jsId which will be the id of the model in your document. If you want to refresh the model just call:

model1.refresh();

The FluxProcessor API

Here are the most important functions the FluxProcessor offers:

dispatchEvent(/*String*/ targetId)

dispatches a DOMActivate to a trigger thereby firing the actions attached to that trigger

Example:
fluxProcessor.dispatchEvent("myTrigger');

dispatchEventType(/*String*/ targetId, /*String*/ eventType, /*Object*/ contextInfo)

dispatches a Event of a specific type to given target id

Example
fluxProcessor.dispatchEventType(this.xfControl.id,"DOMFocusOut");

setControlValue(/*String*/ targetId, /*String*/ newValue)

sets the value of the control with given id to new value

Example:
fluxProcessor.setControlValue("myInput","hello world");

close()

initiate a shutdown of the processor. If dirty data exist and skipshutdown is not ‘false’ a confirmation dialog will be shown.

Example:
fluxProcessor.close();

setLocale(/*String*/ locale)

set the locale for the form. Must be a two-letter ISO 639 code. This will affect the rendering of numbers and dates.

Example:
fluxProcessor.setLocale("de");

showHelp()

shows help in a popup window if any is available for the currently focussed control.

Example:
fluxProcessor.showHelp();

There are some further goodies in API but i leave that for self-study for now. In the majority of cases you will only need setControlValue and dispatchEvent to interact which your forms. With dispatchEvent you can activate any trigger in your document and it can be an easy bridge between the browser world and the XForms processor. dispatchEventType on the other hand lets you dispatch any type of event to the XForms document and even pass some contextInfo if needed.

The XFormsModelElement API

There’s not much you can do with the XFormsModelElement at the moment that you can’t do through functions of FluxProcessor. With one important exception – if you for some reason want the instance data of your form at the client-side then you have to use getInstanceDocument() function.

In betterFORM you have to use the function like this:

model1.getInstanceDocument(/*String*/ modelId, myCallBack);
/*
    A function that receives the returned instance data
*/
function myCallBack(data){
    //if you have Firebug active you can list out the returned XML
    console.dirxml(data);
    ...
}

If you need or want your XML as a String use getInstanceAsString() instead (same arguments).

From XForms to JavaScript

Sometimes you may experience situations where the call to a simple JavaScript function makes life a lot easier.  Probably any XForms implementation out there has some way to do that. In betterFORM we simply use the syntax of HTML:

<xf:input id"input1">
    <xf:label>input1</xf:label>
    <xf:action ev:event="xforms-value-changed">
        <script type="text/javascript">
            dojo.byId("input1").attr("style","background:lightyellow;");
        </script>
    </xf:action>
</xf:input>

In this example the background of the rendered control will be colored in lightyellow when the control gets an ‘xforms-value-changed’ event.

JavaScript has become an important part of modern web applications. There are only few users still accepting a pure request/response oriented interface – the new user interfaces are just too attractive. XForms can hardly be beaten when it comes to complex forms but the same is true for JavaScript in the domain of attractive and dynamic user interfaces. Using JavaScript and XForms together gives you the powerful package you need to build cross-browser and state-of-the-art web applications.

June 16, 2010 at 11:51 am Leave a comment


Recent Posts

betterFORM tweets


%d bloggers like this: