Re: Dynamic @action attribute on xforms:submission

Mark Birbeck wrote:
> Hi Erik,
> 
> An issue very close to my heart!
> 
>> With XForms 1.0 and 1.1 draft, it is not possible to 
>> dynamically specify the @action attribute on 
>> xforms:submission. However, in these days of REST, it is 
>> obviously necessary to be able to do that.
> 
> Well, it's not just REST--you can't even do something simple like read an
> RSS feed that is defined at run time.
> 
> 
>> How have implementors addressed this?
> 
> In the absence of something in the spec, we have two different solutions for
> our two versions of formsPlayer--attribute value templates in formsPlayer 2,
> and the xf:extension element in formsPlayer 1.
> 
> 
>> The following solutions come to
>> mind:
>>
>> o Handle @action as an attribute value template, for example:
>>
>>    
>> action="http://example.org/app/{instance('my-instance')/image-
>> name}/etc"
>>
>>    Benefits: very flexible; XSLT does it so we are not reinventing the
>>    wheel.
>>
>>    Drawbacks: XForms doesn't use attribute value templates anywhere at
>>    the moment. Users will expect that avt will work in other places as
>>    well!
> 
> We use this in formsPlayer 2, and in many ways it's my favoured solution.
> However, since you also need to be able to control the method and headers,
> we've not used this approach in version 1, and instead went for the rather
> laborious, but more powerful, xf:extension technique.
> 
> A good example of how complex submissions can get is illustrated in the
> following post on our skimstone site:
> 
>   http://skimstone.x-port.net/index.php?q=node/219
> 
> In it we discuss making a submission to the Backpack API:
> 
>   Backpack has three further complicating factors; first,
>   your user name is actually used as a sub-domain to
>   access your data:
> 
>     http://yourname.backpackit.com/ws/
> 
>   Second, a specific request header is required--
>   X-POST_DATA_FORMAT must be set to xml. And the third
>   is perhaps the most complicated--the URLs themselves
>   need to be dynamic; for example, to update the content
>   of item 5 on page 1234, the URL will be something like:
> 
>     http://yourname.backpackit.com/ws/page/1234/items/update/5
> 
> 
> 
> I would see this submission to Backpack as a kind of test case for a lot of
> the features that submission needs, so any solution we devise must include
> the ability to set arbitrary headers, as well as compose any part of the
> URL. (They don't use a method that is calculated at run-time, but ideally
> we'd support that too.)
> 
> A submission that works with Backpack that makes use of our xf:extension
> feature looks like this (a full working form is included with the entry on
> skimstone, mentioned above):
> 
>   <xf:submission
>    id="sbm-backpack"
>    method="post"
>    ref="instance('inst-backpack-request')"
>    action="http://dummy/"
>    replace="instance" instance="inst-backpack-response"
>   >
>     <xf:extension>
>       <sub>
>         <action>
>           <part value="'http://'" />
>           <part value="instance('inst-session-data')/backpack-username" />
>           <part value="'.backpackit.com/ws/'" />
>           <part
> value="instance('inst-session-data')/backpack-command-expanded" />
>         </action>
>         <headers>
>           <header name="X-POST_DATA_FORMAT" value="'xml'" />
>         </headers>
>       </sub>
>     </xf:extension>
>   </xf:submission>
> 
> Not pretty...but at least it allows us to control every part of a submission
> whilst we wait for a solution to be specified.
Why not combine the two approaches? Allow AVT for building of the action 
  string (which is IMO much easier and intuitive) and also support the 
'headers' extension for the cases that need it.

And there also seems to be a semantic justification for making this 
difference: while building the URI is a generic requirement that applies 
in potentially all environments you can guess of for XForms the setting 
of some headers is a somewhat special requirement when working with 
specific http-based protocols. The extension mechanism is still the 
right solution to handle this i think.

m2c.

Joern

> 
> 
>> o Extra attribute on xforms:submission, such as @action-ref.
>>
>>    Benefits: does not introduce avt.
>>
>>    Drawbacks: another attribute to remember; requires @action to be no
>>    longer required; doesn't scale to other attributes; *-ref attribute
>>    names are not nice-looking ;-)
> 
> And unfortunately what will probably happen is we then start adding more
> attributes in other places that we would like AVTs. Better to just get on
> and add AVTs.
> 
> 
>> Any other ideas or suggestions?
> 
> My favoured approach is AVTs, but I think we should add them generally,
> rather than just for one or other feature.
> 
> Regards,
> 
> Mark
> 
> 
> Mark Birbeck
> CEO
> x-port.net Ltd.
> 
> e: Mark.Birbeck@x-port.net
> t: +44 (0) 20 7689 9232
> b: http://internet-apps.blogspot.com/
> w: http://www.formsPlayer.com/
> 
> Download our XForms processor from
> http://www.formsPlayer.com/
> 
> 
> 
>

Received on Wednesday, 19 April 2006 22:07:27 UTC