W3C home > Mailing lists > Public > public-forms@w3.org > November 2010

Non-eventable and other thoughts

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Thu, 4 Nov 2010 14:38:28 -0700
Message-ID: <AANLkTika+DC5WUyJpmJU8L_CfNKN_EQa6Gko+DP5-HL2@mail.gmail.com>
To: Forms WG <public-forms@w3.org>
All,

Following our conversation this morning, I am wondering why we need
the non-eventable mode. Or rather, I wonder why we need this in
addition to the non-presentable mode.

It seems like we have established that you should be able to style
non-relevant controls, including hiding them completely, or showing
them on screen but not accessible by the user.

Further, it seems like it might be desirable that the controls update
their values while being non-relevant. Now if they update their
values, I think that they should also dispatch events, as it would be
not consistent for an action interested in tracking
xforms-value-changed for example to lose those changes while the user
is made aware of those same changes.

In XForms 1.1, we say that non-relevant controls are non-eventable,
but I am now wondering what the rationale for that was. It doesn't
seem like this is really needed unless non-relevant controls don't
update on screen at all.

So, hypothetically, if we had a notion of non-relevance that would
still dispatch events, then we wouldn't even need a separate
non-eventable notion. The only case where controls would be
non-eventable would be the case were they're not presentable.

So we might be able to cover the use cases simply by adding one
notion, that of being present or presentable.

For a non-selected case, instead of saying that a non-selected case is
not relevant, we would say that it is either non-presentable or
presentable (pick the default), and that default could be changed. Of
course the semantic for switch case would make it clear that only the
selected case is if you want on top of the stack and actually visible
to the user.

Now if we really do need a separate notion of being non-eventable,
maybe that can be added separately. But I am not convinced that it is
really useful.

The same applies to the proposed notion of active/inactive (which was
a superset of eventable/non-eventable). It seemed like this would be
most useful for the “relevant but visible” mode. But again, if we
decide that non-relevant controls must update their values and show
them to the user, they are not really inactive, are they? They are
just not accessible by the user.

To summarize:

* non-relevant => presentable and not accessible by the user
* relevant => presentable and accessible by the user
* non-selected case => either: presentable (semantic of switch also
enforces that it's not accessible by the user) OR not presentable
* any control: can be made non-presentable with a property, both in
the model and in the view

The benefit of going this route would be that things would be simple:
just one notion to add and the rest is to figure out the syntax.

Alternatively, we could look at the notion of being presentable as
simply a variation on relevance. So, we would still mark a
node/control has non-relevant or relevant using the current
mechanisms, but we would add an attribute to control whether that
particular relevance would be presentable or not. The benefit of this
would be that we would not have a new property but simply add a new
attributes that would statically configure how relevance works. Food
for thoughts.

-Erik
Received on Thursday, 4 November 2010 21:39:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:54 UTC