Hi Aaron
Remember this is not in the specification in any way yet and might
never be.
For me the ease of authoring have priority compared to the
difficulties for the implementor (and I said this in the role of an
implementor ;-) ). I don't even know if the functionality would be
more work for an implementor but I do believe that many authors are
annoyed with having to make binds to the instance for getting this
kind of functionality to work since it would require her to create
three XPath expressions instead of one (1: the bind/@nodeset, 2:
@readonly/@relevant and 3:@ref/@context on the form control). Also
the layering is tedious, e.g. that you have to put expressions that
belongs to the UI in the model; this is many times done in a scratch
instance which does not always work when you are using it in a repeat
and also requires the author to create am instance only to maintain
some states. A third problem is that @readonly/@relevant applies to
all controls bound to the node which is not always what you want. And
lastly @relevance will get removed if irrelevant when submitting
which is many times not what an author want and leads to a pattern of
having a "variable" which controls if the relevant expression should
be applied or not (e.g. it removes the relevant expressions just
before submitting).
Best regards,
David
On Feb 14, 2007, at 1:36 AM, Aaron Reed wrote:
>
> 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
>>>
>>>
>>>
>
>
>