Re: Dynamic @action attribute on xforms:submission

Hi,

To me it sounds like there is a real push for AVT from implementors and 
as long the attributes which can contain AVT values does not changed the 
processing model then there is no problem in implementing it (e.g. 
having AVT in the @model attribute or @ref/@bind is difficult to 
implement where having it in dispatch/@name is easy).

 From an authoring perspective I would *much* rather have AVT than 
writing an setvalue event handler which can change the @action URL. IMO 
AVT is the intuitive solution for this problem.

Best regards,
David

John Boyer wrote:
>
> 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/
> >
> >
> >
> >
>
>
>


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------

Received on Thursday, 20 April 2006 06:29:53 UTC