Re: Support for AVTs in XForms? [WAS: Dynamic @action attribute on xforms:submission]

Erik Bruchez wrote:
> 
> Allan Beaufour wrote:
>> 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).
>>
>> I agree. John mentions that it "keeps coming up over and over and over
>> again.", and I think there is a reason. People want to use it... I
>> definately believe that we should investigate how to include AVT
>> support in XForms -- or once and for all find a definitive reason for
>> why we should not. It's not a foreign concept in "w3-land"...
>> http://www.w3.org/TR/xslt#attribute-value-templates
>>
>>>  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.
>>
>> I agree 100%, but others might think exactly the same for the setvalue
>> approach :) But if both camps can be satisfied, well why not? :)
> 
> I have to concur in favor of the use of AVTs, for the reasons already 
> mentioned.
> 
> I do think the event-modification solution has merits. But with all due 
> respect I think in fact that John's example below is, well, not the best 
> example:
> 
> <xf:submission action="blah" ...>
>     <xf:setvalue ev:event="xforms-submit" ref="event('action')" 
> value="some/node/in/instance"/>
> </xf:submission>
> 
> It is bad because we have here a case where a common and apparently 
> trivial task requires a cryptic line of XML and a deep understanding of 
> XML event processing from the form author, instead of the "intuitive" 
> AVT solution. Simple tasks should be easy to accomplish.
I absolutely agree here. Couldn't have said better.

> 
> This is not to say that modifying events, as a general mechanism, 
> doesn't have value, on the contrary. For example, when you start adding 
> a large number of properties, such as headers, etc., this may become the 
> preferred solution.
> 
> Regarding setting headers, BTW, how would you go about using xf:setvalue 
> to set multiple headers? Would you then pass a second argument to the 
> event() function, e.g. event('header', 'Accept')?
Why not use multiple setvalue action in this case? IMO this would be 
much clearer cause normally setvalue specifies exactly one value.

> 
> Regarding AVTs in general, there are different types of attributes:
> 
> 1. Attribute of XForms, like xf:submission/@action. One question to 
> answer here is whether all such attributes support AVTs, and if not, 
> which do.
At least there are some attributes that will cause a hen and egg 
problem. Consider e.g. instance/@src attribute...

<xf:instance id="foo" src="{instance('foo')/bar}"/>

This would be hard to evaluate ;)

Sure you can establish some extra rules e.g. that the AVT is only 
allowed to point to instances that are already loaded but this can 
easily cause some extra confusion for authors and doesn't feel well for me.

Other attributes will cause further questions like model/@schema or even 
bind/@nodeset.

Before allowing AVTs on any XForms attribute these cases should be very 
well thought over and i would prefer to go the conservative way and 
explicitly allow them on the most useful attributes (like 
submission/@action and load/@resource) before generating a big list of 
exceptions. To cut it short IMO a 'positive' list would be preferable to 
a 'negative' list.

> 
> 2. Attributes of the host language, like xhtml:table/@colspan. In this 
> case, it appears reasonable that all attributes would support AVTs. At 
> least, in the case of HTML, all attributes under and including the 
> xhtml:body element.
While i absolutely agree on the usefulness of such a construct i also 
see problems here:
it just doesn't feel right to allow XForms as an embedded language to 
change attributes of its host language. While this might work with HTML 
(i actually can't find an example where this would cause problems) you 
can imagine that it could cause trouble for some other host language.

Don't get me wrong - it would be absolutely nice to have this cause 
there are so many possible use cases for it and authors would love it. I 
just fear that it might cause some effects that are hard to foresee. 
Maybe i'm just paranoid.

Joern

> 
> The first category addresses the question of attributes that are static 
> but would benefit from being dynamic. The second category addresses the 
> question of modifying attributes of host language elements. Both should 
> be addressed IMO.
> 
> -Erik
>

Received on Tuesday, 25 April 2006 21:39:55 UTC