W3C home > Mailing lists > Public > www-forms@w3.org > April 2006

Re: Dynamic @action attribute on xforms:submission

From: Allan Beaufour <beaufour@gmail.com>
Date: Thu, 20 Apr 2006 10:05:30 +0200
Message-ID: <90d6cb0e0604200105u4affec89v3ee6cb0f7368a94b@mail.gmail.com>
To: "David Landwehr" <david.landwehr@solidapp.com>
Cc: www-forms@w3.org

Imho, we are discussing two different subjects here.
1) A way to dynamically change the action of a submission

If there is a WG decision to do it the way John described, then we've
already solved the issue and all is well :)  I look forward to seeing
it in the working draft, so we can discuss it on that basis.

(I cannot remember the decision, but that does definately not rule out
that I was present at the given f2f ;-) )

2) General usage of AVTs, including one specific solution to 1)

Another mail on that.

On 4/20/06, David Landwehr <david.landwehr@solidapp.com> wrote:
> 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.

http://www.w3.org/TR/xslt#attribute-value-templates

> 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
> --------------------------------------------
>
>
>


--
... Allan
Received on Thursday, 20 April 2006 08:05:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:03 GMT