Re: Readonly, relevant attributes for trigger

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 Tuesday, 13 February 2007 21:04:54 UTC