Re: Readonly, relevant attributes for trigger

All you said is true.  It just seems to me that XForms controls would no 
longer be strictly tied to the instance data anymore.  Now they would 
represent the state of the instance and/or any one of a number of other 
state attributes in some kind of order.

Why attributes on the controls?  Might as well use a xf:bind to place 
the MIPs on the control.  Change @nodeset to @context (optional 
attribute, of course) to potentially give the MIP's a context node to 
work off of.  Then its not so xhtml-ish.  Plus then it feels like the 
control is at least marginally bound to something (the model) and would 
probably be less work for us implementors.

--Aaron

David Landwehr wrote:
> 
> Hi Aaron,
> 
> It is normal to want a control to reflect a state without having to 
> setup binds in the model. The relevance can be done today by using a 
> predicate on a single node binding, e.g. when the single node binding 
> does not point to a node it must behave as irrelevant. I use that a lot 
> on triggers and groups:
> <xf:trigger ref="self::node()[ condition=condition]"/>
> 
> This however have some side effects as the control will start to have 
> events dispatched from it. It would be much easier for the author to be 
> able to leave out this single node binding and instead have the boolean 
> XPath expression on a different attribute.
> 
> For readonly there are no way something similar can be achieved today 
> and the only option is to create a bind/@readonly and the bind the 
> control. For me this is not a big deal because controls that want to be 
> readonly surely is bound to an instance node since it has to do with 
> accepting input. This is not the case with relevance on trigger and 
> group (group for model based switch/case functionality) , where the a 
> bind would have the sole purpose of attaching the relevance state.
> 
> You are absolute correct that the same functionality could be achieved 
> from CSS. However that would require that the CSS selection can match 
> based on the bound data, which is not the case today. If CSS had a xpath 
> "pseudo function" the effect could be achieved like that. This would 
> however create a problem where crucial form/UI functionality would not 
> run on a general XForms processor, because CSS is not a normative part 
> of XForms.
> 
> Best regards,
> David
> 
> 
> On Feb 13, 2007, at 8:40 PM, Aaron Reed wrote:
> 
>>
>> Hi Erik,
>>
>> Relevant and readonly attributes on xf:controls?  Really?  There might 
>> be some really good use cases that the W3C is looking at to consider 
>> this but my first reaction is, "ewwwww".  Relevancy and readonly-ness 
>> is the state of the instance node and the control is just reflecting 
>> that state.  Why would a control be relevant or readonly if it isn't 
>> bound to data?  I can see a form author wanting to make a button 
>> appear or disappear easily with an attribute since the button isn't 
>> bound to instance data, but they can already do this with CSS.  Or 
>> heck, they can use a native widget from the host language and use the 
>> attributes that that native widget already supports.  Nothing wrong 
>> with having a xhtml:button in a xhtml document or a xul:button in a 
>> xul document.  You can listen for a DOMActivate on a native widget 
>> just as easily as on a xf:control.
>>
>> I guess that I just don't get the value of adding attributes like this 
>> to the XForms spec.  Can you give an example?
>>
>> Thanks,
>> --Aaron
>>
>> Erik Bruchez wrote:
>>> Guntis Ozols wrote:
>>>> In real life, for me it means that I have to create helper instance 
>>>> + helper
>>>> bindings (bloating, again), just to manage relevant/readonly for 
>>>> buttons,
>>>> because there is NO node in instance data with proper values for these
>>>> attributes. If that's the intention, could this be clarified in the 
>>>> spec.
>>>> Otherwise, attribute solution is  preferred.
>>> While this won't be in XForms 1.1, the XForms Working Group has been 
>>> thinking about allowing model item properties directly on controls. 
>>> As you correctly point out, this can simplify the code, like with 
>>> triggers as you point out, but also in the spirit of smoothing the 
>>> transition from HTML forms to XForms and allowing developers to 
>>> create a model only when really necessary.
>>> -Erik
>>
>>
>>
> 
> 
>

Received on Wednesday, 14 February 2007 00:40:26 UTC