Re: Conclusion to effects of readonly on trigger

Hi guys,

I think the spec says something slightly different.

The spec doesn't say that non-relevant controls shouldn't receive events.

In the fine spirit of compromise, we actually ended up with this: "When a 
form control becomes non-relevant, it must receive event xforms-disabled 
and then the XForms action handlers that are listening for events on the 
non-relevant form control must be disabled."

The intent here was to ensure that event handlers for non-relevant 
controls don't run.  This *may* be because the implementation is 
server-side and it doesn't deliver non-relevant controls to the client, 
ergo they don't have event handlers.  Or the implementation may be 
client-side, in which case we wanted to guarantee that the XForms-authored 
event handlers do not run *without* prescribing any other side effects 
(such as DOM mutations that might occur if one were required to physically 
delete the non-relevant controls from the DOM).

Via host language features, a non-relevant trigger will not be able to be 
activated because it is either not presented or presented as disabled, so 
those might be reasons why a DOMActivate would not even be dispatched to 
the trigger.  But XForms doesn't actually prescribe that.

The intent of unhooking the XForms-based action handlers was to make sure 
that XForms was doing its part to make non-relevant controls unavailable. 
A key issue being addressed was ensuring that handlers for xforms-invalid 
don't run on things that are non-relevant.  They're not relevant, so we 
shouldn't be bugging the user with things that are invalid.

But there are players besides XForms that can still "see" the controls if 
they are in the live running document DOM.  So in theory you could 
programmatically dispatch a DOMActivate to a non-relevant trigger, and it 
*would* receive the event.  Because that's what XML events does.  But the 
DOMActivate handlers written by the XForms authors won't run, because 
that's what XForms does :-)

Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: public-forms-request@w3.org
05/02/2007 09:33 PM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc

Subject
Re: Conclusion to effects of readonly on trigger







Good point.

I thought we already specified that non-relevant triggers cannot be 
activated, but I can't find anything about this.

I know that our implementation doesn't allow non-relevant controls to 
dispatch any event.

Do we have a use case in favor of allowing non-relevant controls to 
dispatch events?

-Erik

Mark Birbeck wrote:
> 
> Hi John,
> 
> I think that captures it. :)
> 
> The other thing that came up, which I for one hadn't thought of
> before, was a need to clarify the behaviour of xf:triggers when they
> appear inside a non-relevant group, or are themselves non-relevant. We
> know that non-relevant controls should not _receive_ events, but
> should we say that they don't initiate them either? In other words,
> clicking a xf:trigger should have no effect?
> 
> To clarify the situation I'm thinking of, we've said (at least in
> XForms 1.1) that non-relevant controls act as if they aren't there in
> the UI, and therefore don't receive events. But it is possible that
> some processor might choose to render the controls--perhaps in a
> greyed out style--but still not give them any events. That processor
> would still have implemented the specification correctly. This
> therefore opens up the possibility that a user could click on a
> 'disabled' trigger, which in turn means that we need to be explicit
> about the fact that the control should not generate any events.
> 
> Regards,
> 
> Mark
> 
> On 02/05/07, John Boyer <boyerj@ca.ibm.com> wrote:
>>
>> I think we were pretty close to a conclusion on the telecon about the
>> interpretation of the readonly MIP for trigger.
>>
>> Whatever the decision, it seems worthwhile make note of it in the spec 
>> given
>> that we had some work to do getting through the points ourselves.
>>
>> Let's see if we can get this wrapped up on the list during the week 
>> and/or
>> get a clear statement of resolution that folks can vote on next week if
>> necessary.
>>
>> Here is what I understood from the discussion:
>>
>> 1) Like all other events for MIPs, the xforms-readonly and 
>> xforms-readwrite
>> events are received by a trigger bound to a node (when the processing 
>> model
>> says those events are to be dispatched, of course).
>>
>> 2) The readonly MIP is a statement about the what can happen to the 
data
>> node.  Since a trigger does not directly manipulate the data node via 
>> its
>> UI binding, there is no direct relationship between the data node being
>> readonly and presentational properties of the trigger.  Specifically,
>>
>> a) The ability to activate a trigger is not disabled if the trigger is 
>> bound
>> to a readonly node
>> b) The default countenance of the trigger is unaffected, i.e. it does 
not
>> take on a disabled countenance
>>
>> Cheers,
>> John M. Boyer, Ph.D.
>>  STSM: Lotus Forms Architect and Researcher
>>  Chair, W3C Forms Working Group
>>  Workplace, Portal and Collaboration Software
>>  IBM Victoria Software Lab
>>  E-Mail: boyerj@ca.ibm.com
>>
>>  Blog:
>> http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>>
>>
> 
> 


-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/