xforms
Submitted by administrator on Fri, 03/05/2010 - 02:12.
Lotus Forms has supported XForms for a number of years now, and you can get a good idea of all the features supported from the XFDL reference manual.
However, now that XForms 1.1 has been finalized, I've had a number of questions about shining a spotlight on the XForms 1.1 specific features in Lotus Forms. Quite a number of XForms 1.1 features were improvements to the semantics of pre-existing XForms 1.0 features, and no small number of those improvements were based on feedback from the IBM Victoria Software Lab, so obviously we implement those and it would be too long to go into them. The spotlight will be on Lotus Forms features syntactically activated with new XForms 1.1 vocabulary that was not available in XForms 1.0.
One of the coolest and most powerful additions to XForms 1.1 were the if and while attributes on XForms actions. XForms actions are behaviors like changing data values, insert or deleting nodes, or making web service calls, and they can be set to happen in response to events like a button press (DOMActivate) or user input (xforms-value-changed). The if and while attributes enable XForms actions to be conditionally or iteratively executed when these events occur.
Lotus Forms supports the context and origin attributes on insert and delete actions. These attributes enable handling of empty repeating data, and they allow repeating data to be copied from a data template. It is much easier to handle dynamic table data with these features. Also, when deleting a data node representing a row of a table, if the table becomes empty, then the above if attribute can be used on an insert to detect that this has happened, and insert a new empty data node. The net result observed by the user is that deleting the last row of a table looks like it just clears out that row so that the user can start immediately entering more data.
Lotus Forms also implements the XPath function compare(), which means a form author could use XForms actions with the if and while attributes to sort or search data, if the need arose. Several other functions are implemented, including:
-
random() - in case you want to write a Lotus Form that plays Black Jack
-
current() - to help with data table lookups
-
power() - for exponential calculations such as compounded interest payments
-
days-to-date() - can be used in combination with days-from-date() to do simple date math like "today plus 90 days"
-
seconds-to-dateTime() - can be used in combination with seconds-from-dateTime() to do dateTime math like "now plus 3 hours"
-
local-date() - provides the date for the end-user, rather than the UTC date
-
local-dateTime() - provides the end-user date and time, rather then the UTC date and time.
Lotus Forms supports the display of images obtained from XForms instance data, in both button and label items, using the mediatype="image/*" attribute setting on xforms:output.
Lotus Forms supports the xforms:* datatypes, which allow an empty string to be valid on the corresponding xsd:* datatypes, like xsd:date. Whereas pure XML schema datatype definitions are intended to define what constitutes valid completed data, this feature of XForms recognizes the importance of a good user experience before and during completion of the form.
Finally, Lotus Forms supports several of the new features of xforms:submission, including:
- the method="put" and method="delete" attribute settings to round out access to ATOM publishing services
- the relevant and validate attributes, which allows a submission to turn off data validation and relevance pruning. This can be used to implement a "Save to Server" capability so that a user can perform a fill experience over multiple sessions.
- the serialization="none" attribute setting to enable an xforms:submission to perform simple URL activation.
- The targetref attribute, which enables a web service call to replace only a portion or subtree of a data instance.
- The replace="text" attribute setting, which allows a web service call to replace the content of the target data node, rather than the data node itself. This is useful for accessing web services that return textual content rather than XML.
Lotus Forms also has a number of XFDL extensions that add value to the integration with XForms, but that is the subject of another blog for another time.
Submitted by administrator on Wed, 01/20/2010 - 08:06.
I asked this on the XSLTForms list, but it’s worth casting a wider net.
Say I have an XML instance like this:
<root>
<format>xml</format>
</root>
Possible values for the format element are “xml”, “text”, “binary”, or a default setting, indicated by a complete absence of the <format> element. I’d like this to attach to a select1 with four choices:
<xf:select1 ref=”format”>…
* [...]
Submitted by administrator on Mon, 01/18/2010 - 12:41.
Since URIs are often conveyed as strings it's tempting to manipulate them as such, but it's better--and safer--to delegate URI manipulation to special functions. These can then have their own unit-tests, which will take into account the edge-cases that can catch us out.
<!--break-->
I've just been doing a quick code review in the Ubiquity XForms project, and one thing caught my eye that I thought might be worth a post.
Forms submission
In forms submission -- both in XForms and HTML forms -- we often need to add parameters to a URI.
For example, if we have the URI http://example.org, and the parameters a=b and c=d, then the resulting URI should be:
- http://example.org?a=b&c=d
It seems pretty straightforward that we need to add the parameters to the URI, with a '?' in between:
- [uri] + '?' + [parameters]
Adding parameters
We can see that the parameters themselves have been added by taking the name and value (a=b, etc.), and adding it to the URI, ensuring that for all parameters other than the first, there is a separator between. (The separator can be either an '&' or a ';'.)
Base URIs already containing parameters
The bug that needed fixing though, was that this 'naive' concatenation doesn't work if the URI you are dealing with already contains parameters.
For example, if we have the URI http://example.org?x=y, and we need to add the same two parameters we had before, then our simple concatenation would give us:
- http://example.org?x=y?a=b&c=d
when what we actually need is:
- http://example.org?x=y&a=b&c=d
As you can see, if we already have a '?' then we don't need to add another, so it seems that a simple addition to our concatenation code would be to use a call to indexOf to see if there is a '?' present, and only add another if we don't find one.
There's a small additional test we'll need to make which is to check whether the last character in the URI is a '?', as I'll explain.
Base URIs with empty query strings
Recall that we added the parameters by placing a=b and c=d onto the end of the URI, separated by '&':
- http://example.org?a=b&c=d
Now, if we already have a URI with a query then we need to ensure that there is an additional '&' placed before our first parameter:
- http://example.org?x=y&a=b&c=d
But what if the base URI has a query indicator (i.e., the '?') but no parameters? In other words, what if we have this URI:
- http://example.org?
In this situation we don't want to add the extra separator, otherwise we'll get this:
- http://example.org?&a=b&c=d
So our rules now become that we only want to precede our parameters with a separator if the '?' is not the last character in the URI. It's a little awkward, but thanks to lastIndexOf, I'm sure we can manage.
Base URIs already containing fragments
However, there's a further subtlety; what if the URI contains a fragment identifier?
For example, if we have the URI http://example.org#x, and we need to add the same two parameters we had before, then our simple concatenation would give us this:
- http://example.org#x?a=b&c=d
The fragment identifier part of the URI has now become x?a=b&c=d because it's always the last part of the URI. What we actually want is to insert the new parameters before the '#':
- http://example.org?a=b&c=d#x
Now we need to add another use of indexOf to check for a '#', and if we find one, use its position as the point at which to insert the parameters.
Context is everything
However, the assumption behind using indexOf and lastIndexOf in this way is that a URI will contain only one '?'. A secondary assumption here is that the only time you'll ever see a '? is as an indicator of the query part of the URI.
Both of these assumptions are incorrect.
Question marks in parameters
The first assumption is that you can only have one '?' in a URI. However, the query section of RFC 3986 explicitly flags up that the '?' character is a valid parameter value. For example, we can have a=finished? as a parameter.
This means it's quite easy to envisage scenarios where there is more than one '?' in the URI:
- http://example.org?a=finished?&c=d
This won't necessarily mess up our first use of indexOf, but it will mess up the use of lastIndexOf as a way to check whether you need to add an extra separator. Recall that we wanted to avoid turning this:
- http://example.org?
into this:
- http://example.org?&a=b&c=d
so we used lastIndexOf to check whether the last character in the URI was a '?'. But that algorithm will turn this:
- http://example.org?a=finished?
into this:
- http://example.org?a=finished?c=d
You might need to look closely to spot it, but because the last character was a '?', we haven't added a separator before the c, and as a result, instead of having two parameters (a=finished? and c=d) we have only one (a=finished?c=d).
Question marks in fragments
The interesting thing about the previous examples is that at least you know you have a query string, so you might be tempted to still use indexOf to manipulate things. After all, although we may have too many '?' characters, we still know that we have query.
However, with the the fragment section of RFC 3986 all bets are off; here we can see that '?' is explicitly allowed as a fragment character.
This means that it's possible to have a '?' in a URI even if it doesn't have a query. For example:
- http://example.org#finished?
This may seem like a contrived example, but actually it's not, for two reasons.
The first is that the fragment part of a URI is carefully defined to allow anything, because we don't know how it will be interpreted. You may think that "finished?" is not valid as an HTTP fragment, but what about in the scheme "xyz"?
And this is the key point; since HTML forms and XForms can ultimately deal with any scheme, since that's how the web is designed, we must write our algorithms defensively, and not assume anything.
Safe URI handling
Hopefully this delving into some of the subtleties of URI handling and parsing--and we haven't even begun to talk about turning relative paths into absolute paths, handling encoded characters, and so on-- has done enough to convince you that you shouldn't manipulate URIs directly, as simple strings.
The only way to be completely sure of what is happening is to use special functions to unpack a URI into its various components, then manipulate those components--perhaps adding additional parameters to the list of query parameters, but it might also be to turn a relative path into an absolute path--before finally reassembling the URI.
This may sound like a lot of work, but it's the only way to be sure that characters don't get incorrectly interpreted as a consequence of their position in the URI not being taken into account.
In the backplanejs library these functions are in the URI module. (This is also imported into the Ubiquity XForms library.) Breaking up a URI simply involves calling spliturl, which returns an object containing all of the parts. For example:
- spliturl( "http://example.org?a=finished?" )
would give us the object:
- {
- scheme: "http:,
- authority: "example.org",
- path: ""
- query: "a=finished?"
- fragment: ""
- }
It's then an easy matter to manipulate the query part, before creating a new URI with the recomposeURI method.
Conclusion
Since URIs are often conveyed as strings then it's tempting to manipulate them as such. But the problem with doing this means that the context of a character is rarely taken into account when processing.
It's better--and safer--to delegate URI manipulation to special functions. These can then have their own unit-tests, which will take into account the edge-cases that can catch us out.
Submitted by administrator on Mon, 01/04/2010 - 19:47.
As we start off the business of a new decade, I already find myself looking forward to the improvements in XForms 1.2.
I know, I know, we just released the XForms 1.1 Recommendation, which contained a huge bundle of new features and architectural improvements. Still, the working group has been energetically advancing on still more features and improvements even as we closed the loop on the W3C process in the latter half of last year. I am very pleased with the completion of XForms 1.1, but the only constant is change, and we have an excellent array of new technical results to achieve in XForms.
The working group has put a fair bit of effort into the triage of features to separate nearer term (and simpler) objectives from those features of a more architecturally significant nature, which tend to get put in the "XForms 2.0" bucket.
My personal favorite "simple" feature is model-based UI switching with the switch element. This may seem like a bit of a nerdy thing to perseverate on, but the switch element is the only UI control we have that is not directly controllable by a UI binding to data. So, if a form author wants to switch UIs based on a user input, such as changing the payment details UI based on the selection of a payment, then the form author typically resorts to using group elements and the relevant model item property. But this is more than just the sense of completion we'll get from being able to say *all* UI controls can be declaratively linked to data. And it's more than just the satisfaction we'll get from providing the right tool for the job. The ability to declaratively link the state of a switch to data is critical to the save/reload web application pattern and the transaction digital signature web application pattern.
Other web application standardization efforts are focused mainly on what happens during execution of a single web page. XForms-based technogies are a step ahead because they can more easily address the user patterns related to collaboration on the web. Whether it is one user saving an application context and reloading it again in the future, or whether one user provides data to be loaded by a second user, the simple fact remains that data can be in any state along a continuum between empty template and fully completed, so web applications need to be declaratively responsive to that continuum. And nowhere is this clearer than when a web-based transaction is of high enough value to warrant a digital signature. A digital signature needs to be able to capture the full current state of the web application, and having a declarative binding to the data is the easiest way to achieve that goal since it means one can simultaneously sign the web application page template(s) and the data as separate resources.
For the record, Lotus Forms has for a few years now used a legitimate XForms extension mechanism, the xfdl:state attribute, to support model-based switching. We deemed this extension critical to our ability to address our customers' requirements for the above two web application patterns. Standardized integration of XForms with XML Signatures and other advanced security features like XAdES is, so far, in the XForms 2.0 bucket.
In conclusion, I'm not necessarily saying this is the "biggest" feature of XForms 1.2, only that it is my fave. I'll be giving some coverage to the other XForms 1.2 features in future blog posts, so please click the 'follower' button above (top right) and stay tuned.
Submitted by administrator on Sun, 11/29/2009 - 21:09.
One of the lead bullets describing why XForms is cool always mentions that it is based on a Model View Controller framework. When building a full XRX app, though, MVC might not be the best choice to organize things overall. Why not?
Consider a typical XRX app, like MarkLogic Application Builder. (You can download a your [...]
Submitted by administrator on Wed, 10/21/2009 - 19:04.
I’ll be speaking next Tuesday (Oct 27) at the Northern Virginia MarkLogic User Group (NOVAMUG). Here’s what I’ll be talking about.
Application Builder consists of two main parts: Search API to enable Google-style search string processing, and the actual UI wizard that steps users through building a complete search app. It uses a number of technologies [...]
Submitted by administrator on Wed, 10/21/2009 - 07:01.
XForms 1.1 is now a full W3C Recommendation. Compared to version 1.0, which went live a bit more than 6 years ago, version 1.1 offers lots of road-tested tools that make development easier and more powerful, including new datatypes and XPath functions, a significantly more powerful submission subsystem, and a more flexible event model.
And XSLTForms [...]
Submitted by administrator on Tue, 10/20/2009 - 21:24.
The theme song to Star Trek started to play in my head last night when I thought about the imminent publication of XForms 1.1 as a W3C standard (which the W3C calls a Recommendation). It's been five years since I started putting the working group's content into the first "thin spec" working draft of XForms 1.1.
Since that time, the working group has substantially upgraded XForms to enable it to better address the emerging requirements of cutting edge web applications and interactive documents. This has included well over a thousand spec changes to resolve differences in understanding both great and small. Many times it has happened that one person's editorial clarification is another's substantive change, so there was a significant improvement in mindshare and consensus at a much deeper level than was the case for XForms 1.0.
The biggest change, in my view, is the substantial increase in web connectivity features added to the XForms submission module. This enables XForms to properly act as a smart Web 2.0 application client. XForms handles the interactive rich user experience of the web application, and at any point in that interaction, XForms can directly inject information into and extract information from server-side data sources and business processes exposed as web services, REST services, ATOM feeds and publishing services, etc.
As powerful as these features are when used within a web application's HTML pages, they are all the more interesting when used to connect open standard ODF office-style documents to data sources and business processes. Then, you get the blend of ease-of-user and familiarity features of a word processing or spreadsheet document and the desirable connectivity features of a Web 2.0 application. For further details on these thoughts, please see my document engineering conference papers on ODF and XForms: "Interactive Office Documents: A New Face for Web 2.0 Applications", "An Office Document Mashup for Document-Centric Business Processes", and "Enriching the Interactive User Experience of Open Document Format" (these papers are likely to be available to you through your institutional account with the ACM, e.g. through KnowledgeGate for IBMers).
There are many other additions and refinements in XForms 1.1, which are summarized in the introduction. Suffice it to say that five years of effort have gone into making XForms ready for prime-time, and we at IBM are very pleased to see this version of XForms advance to W3C Recommendation, especially due to the number of products we already have in market that support this computing industry standard. With XForms 1.1, we will soon be able to realize the vision of delivering Web 2.0 applications via "A REST Protocol and Composite Format for Interactive Web Documents".
Submitted by administrator on Wed, 09/23/2009 - 06:14.
Another XForms site launched this week. This one seems pretty close to what I would like XForms Institute to become, if I had an extra 10 hours per week. -m
Submitted by administrator on Tue, 09/01/2009 - 23:20.
Ubiquity XForms version 0.7 is now available. In addition to contributing to the recent advancement of XForms 1.1 to Proposed Recommendation, this new version has many new features, fixes and highlights. Personally I'm happiest with the progress on implementing submissions, but that may be a bit of bias because I contributed some code to deal with aspects of submissions such as serialization, validation and relevance pruning. On the other hand, I contributed code in other areas, so maybe it's just that I'm biased toward any improvements to our ability to support the XRX architecture and connect the XForms client to server-side services.
In any case, there's lots of good core XForms features that have been added as well as noteworthy extension features. My personal favorites are the calendar and checkbox controls used for date and boolean type XForms inputs, the new map controls, and the very simple javascript function extension. Check out the loan-lowercase.html sample and its format.js file, for example.
And this blog entry would not be complete without my mentioning a special word of appreciation to the folks at webBackplane for all their contributions in general but especially for the Ubiquity XForms rollup system, which consolidates the many files of the processor into a single file to be deployed on your server. I have an internal project right now that uses the rollup, and it provides us with the high level of performance we expected/required in our applications.
Full details of the version 0.7 release can be found here: <http://code.google.com/p/ubiquity-xforms/wiki/Release0Point7>
Submitted by administrator on Sun, 08/23/2009 - 13:18.
<!--break-->
We use Google Code a lot in our projects, because it provides a great range of tools, with a straightforward interface.
It's particularly useful to have version control and issue-tracking in the same system, and it's very easy to cross-reference the two by referring to revisions in issue comments, and to issues in the commit messages.
On top of that, Google Code provides some nice code review facilities, and here too, it's possible to refer back to revisions and issues.
In this post I'll outline how we use these tools together in UXF, the Ubiquity XForms AJAX library.
Everything should have an issue
The first thing that's needed is an issue. This might be an issue in the traditional sense, of a bug. But it might also be a desirable feature, that someone would like to add. Whatever it is, we shouldn't really be starting to code until we've written down what we're going to do, or what problem we're trying to solve.
Let's use issue 515 as an illustration. At the top we see it has the following description:
We need a UI control that can adhere to data binding restrictions for
xsd:boolean / xforms:boolean. The control may render a checkbox, for
example.
Sample code snippet:
<xf:input ref="check" datatype="xforms:boolean">
<xf:label>Check: </xf:label>
</xf:input>
Based on conversation with John in last week's call, needed in this
iteration (setting priority to critical).
Code reviews and issues
This description is plenty to get started with, so Rahul gets on with his development and testing, until he is ready for a code review. When he is ready, he commits his code to the review area, with the following SVN message:
[ issue 515 ] Proposed changes for adding a UI control that can bind to boolean
data (renders a checkbox).
You can view this commit at r2919, and as you can see, Google Code provides a convenient link to all of the files involved in the commit. GC also provides tools for attaching comments to any line in those files.
This revision therefore becomes the location at which the review is conducted, perhaps involving many comments from many reviewers.
But note also that Rahul's reference to "issue 515" has become a link to the issue itself. This means that a reviewer has everything they need to start reviewing -- links to all of the files that have changed, a reference to the issue being addressed, and some tools that allow them to add comments to the files.
However, anyone viewing the issue directly would not necessarily know that it was being worked on, or what the progress was. So to keep things up-to-date, Rahul added the following comment to issue 515:
Code for such a UI control has been proposed for addition in r2919 and review
requested. Changing Status to InReview.
The issue is now not only marked as being InReview, but we also have a convenient link to the code review itself. If you were interested in this issue, you would now be able to add your comments to the review, try out the proposed code, and so on.
Committing the code to trunk
At some point the review will finish, and the code will be ready to go into the trunk. (There may be other reviews first, but at some point the cycle should end.)
In our example, Rahul commits his reviewed code to trunk at r2920, with the following message:
[ issue 515 ] UI control that can bind to boolean data. Committed after favorable
review of r2919, with suggested filename change.
Note that we still have a reference to the issue number, but most importantly, we have a reference to the code review at r2919. This means that anyone looking at the code that is committed, and who wanted to understand why a particular change was made, could find the history of the discussion in the code review.
But we're not finished yet.
If we go back to the code review at r2919, we'll find that the last comment Rahul has added says:
Committed to trunk in r2920.
Now, anyone who stumbles across the code review directly knows that the code they are looking at really did find it's way into the trunk, and wasn't left hanging there uncommitted, or was abandoned in favour of some other solution.
Closing the issue
The final step is of course to close off the issue, and here it's important to refer to the revision at which the code was committed. In our example, the last comment on issue 515 is this:
Committed to trunk in r2920 after favorable review.
Resolving issue as Fixed.
Now anyone interested specifically in the issue can see not only that it is closed, but also where the code is that addressed the issue.
Conclusion
This technique may seem a little laborious, but it actually takes longer to describe than to do.
And by following these steps we ensure that we know how a sequence of comments ends, whether in an issue or code review.
We need to know how an issue was addressed when it gets marked as fixed, we need to know what happens to code after a positive code review, we need to know where some code came from that is committed to trunk; in short, no matter whether you are looking at one of committed code, an issue, or a code review, these procedures ensure that you can easily find the other two.
Submitted by administrator on Fri, 08/14/2009 - 22:31.
The XForms 1.1 specification was approved for transition to Proposed Recommendation. Publication as a Proposed Recommendation is currently expected next Tuesday.
In order to achieve this transition, we presented a report of multiple implementations of XForms based on an expansive test suite, we presented the disposition of all formal comments received on the candidate recommendation, and we presented the important changes, which were those changes that the community would reasonably want to hear why they were not substantive deviations and were interoperably implementable.
Advancement to Proposed Recommendation essentially says we're "putting it to a vote" now. The member companies of W3C vote on advancement of XForms 1.1 to Recommendation, and they have until Sept. 22 to cast their votes. Based on the many significant improvements that have been made in XForms 1.1, and the rigorous standardization process we have followed, we are obviously quite optimistic about the outcome of the vote.
I am also especially pleased that both the IE7 and FF3 browser implementations of Ubiquity XForms were included in the implementation report.
Submitted by administrator on Thu, 07/30/2009 - 00:18.
Back in March, I wrote about the open standards basis of Lotus Forms documents. This entry included comments on the use of the XML Signatures standard in combination with XForms within the XFDL markup of Lotus Forms.
Now I'd like to draw your attention to a developerWorks article we've now published on the technical details of Verifying Lotus Forms XML Signatures with Java. This article explains how a JSR 105 compliant implementation, such as can be found in the Apache security library or in Java 6, can be used validate the XML signatures created by the Lotus Forms client software (either the Web Form Server or the client-side Forms Viewer plugin).
Generally, a Lotus Forms document consolidates the client-side of the business process function. This could be a many-step process for an individual or it could be a process that spans many individuals who are collaborating to perform a business transaction. Applying an XML signature on a Lotus Form protects the markup of the consolidated client experience, not just the transactional data created by users. Users don't "see" the XML markup of data for a transaction. They visually see (or aurally sense with accessibility software) the whole "contract" that gives context to the data content. An XML signature applied by Lotus Forms client software signs the whole agreement. The above mentioned article explains how open standards based software can be used to complete the server-side function of validating the XML signatures in order to secure the transactions of a business process. Since Lotus Forms are XML documents based on XForms, this means that the entire business process workflow on a Lotus Form can be achieved with open standards based software.
|
