Re: Dynamic @action attribute on xforms:submission

This keeps coming up over and over and over again.
We have discussed AVTs numerous times in the past in face to face 
meetings, as well as other 
more hacky ideas like dropping a submission into instance data...

The solution we agreed to do for XForms 1.1 would provide the 'action' as 
a component of 
event context in xforms-submit so that an action handler could run a 
setvalue to change it.
This also allows us to add other stuff to the event context, like content 
header, that need to
be changed.  This would allow us to do *all* dynamic configuration of 
submit using a single
mechanism that can be further extended over time.

The reason why this is not already in any specs of the working group is an 
issue that I am
going to flip over to the working group mailing list.

Moreover, since we have only recently decided to move our technical 
discussions to the
public list to give the community a better idea of how much stuff we work 
on, the prior discussions 
of this issue containing markup examples are in the group mailing list 
archive, not the public archive.
So, here is an example:

<xf:submission action="blah" ...>
    <xf:setvalue ev:event="xforms-submit" ref="event('action')" 
value="some/node/in/instance"/>
</xf:submission>

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Joern Turner <joern.turner@web.de> 
Sent by: www-forms-request@w3.org
04/19/2006 03:07 PM

To
Mark Birbeck <mark.birbeck@x-port.net>
cc
www-forms@w3.org
Subject
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/
> 
> 
> 
>