The other day I had what could only be described as a 'Roy Scheider moment'. You know the bit in the film Jaws where, as Police Chief Brody, he's sitting on the beach and just when he becomes aware of people shouting 'Shark' the camera tracks-in whilst zooming-out at the same time. It's a great effect that gives you an impression of that moment when surprise and a greater awareness converge.
Well, whilst debugging an XForms enabled application (quite mundane by comparison) with a combination of the Mozilla XForms, XForms Buddy and Firebug plug-ins I noticed something rather unusual. GET requests against an empty
xf:instance were generating URIs with many parameters, which is rather odd when you consider the actual request URI specified for the
xf:submission element had no parameters at all. I could see the submitted URI from the Net tab in Firebug. The URI looked, for all the world, just like an
application/x-www-form-urlencoded submission should do, except the GET request was made, as previously stated, against an empty
xf:instance. However, there had to be something in the instance data for the serialization to have generated the parameters!
<xf:model xmlns:xf="http://www.w3.org/2002/xforms"> ... <xf:submission id="retrieveService" mediatype="application/xml" encoding="UTF-8" method="get" replace="instance" instance="service"> <xf:resource value="'http://localhost:8888/app'"/> <xf:header> <xf:name>Accept</xf:name> <xf:value>application/atomsvc+xml</xf:value> </xf:header> </xf:submission> <xf:instance id="service"/> ... </xf:model>
The truth was revealed when I opened-up XForms Buddy and viewed the instance data in question. The Mozilla XForms plug-in had exposed the host document, XForms and all, as the content of the empty
xf:instance. How odd. I mean, what good is that? That's when it struck me, in a Roy Scheider sort of way, this was Reflection, the ability of a program to look at itself and change its behaviour.
You can set-up data bindings to the host document that enable you to access information that would otherwise be unavailable to XForms. One example might be that you have generic form components that are included, server-side, into the application but require context information. You could have applied server-side transforms to contextualize the forms or alternatively, you could keep the XForms untouched and use Reflection to access the context information from the host document.
This is, on the face of it, just like XSLT's ability to access the current style sheet by calling the
document('') function with an empty string as its argument. There is an article that covers XSLT Reflection by Jirka Kosek. However, unlike XSLT, this behaviour in XForms is not part of the W3C XForms 1.0 recommendation, or for that matter the forth-coming recomendation for XForms 1.1. I've not been able to recreate this behaviour on other XForms implementations (I've not tried them all yet), but that's not surprising really when you consider it is a non-standard feature. As a means of accessing the host document, it is not ideal either. If it were to become a feature of XForms, then access to the host document should be via a specific function call.
All that said, I must admit I did get rather excited at the prospect of reflective programming with XForms but there is more work to be done before that becomes a reality.