RadioButton in Forms and Dialogs

Hi,

Context for the ML: we have reverted

commit 2d4b87f0c1bfd97185a89c18d5b7680d11a958d6
Author: Michael Stahl <mstahl@redhat.com>
Date:   Mon Aug 18 18:08:37 2014 +0200

    ODF export: don't write invalid "group-name" attribute

    Radio buttons are grouped via their "form:name" attribute already.

    Change-Id: I9f8b27a2904d947c3d4665495d36961e3e41d2c6


in master and libreoffice-4-4 because:

1) It made the change also for "dlg:group-name" to property "Name"
   which maps to attribute "dlg:id", where there was no reason for it,
   and where it broke hard since the implementation assumes and checks
   unicity of the name (as the XML attribute name "id" suggests).

   dlg: is user (script) dialogs (the thing managed by Tools / Man

2) It also didn't correctly plan for backwards compatibility in forms
   (its target) at several levels:

   * properly handling existing files with a form:name and a
     *different* form:group-name on the same RadioButton, leading
     to RadioButton supposed to be in the same group that are NOT, and
     thus not mutually exclusive anymore.

   * there *must* be a way to retrieve a specific RadioButton through
     public API.

   * old scripts should continue to work


This thread is to consider whether, and how exactly, we can do
something like that for 4.5.


The issue the reverted commit tried to fix is that *currently* in
LibreOffice RadioButtons (in forms *and* in dialogs), RadioButtons
(that is "checkboxes" that are automatically mutually exclusive within
 their group) work as follows:

 * They have something which is displayed UI-wise, as "Name"
   property, like every control. It is stored in the
   XML as form:name or dlg:id, respectively.

   In both cases, it is actually also programmatically a property
   "Name" in the Model of the control.

   In dialogs, this name has to be unique, and can be used
   to programmatically get the control object.

   In forms, the name need not by unique, but since it is AFAIK the
   most convenient / robust way to programmatically retrieve a control
   object (the other way is by index, which is not that stable...), I
   usually recommend to use unique names and retrieve controls by
   name.

 * They have something which is shown UI-wise as "Group Name"
   property, which is specific to RadioButtons. The current behaviour
   is that every RadioButton that has the same "Group Name" are
   mutually exclusive. Note that (for database bound controls), they
   do not have to be bound to the same field.

   In both cases, it is actually also programmatically a property
   "GroupName" in the Model of the control.

   This seems to be managed by the control container
   model, the corresponding interface is css::awt::XTabControllerModel

   Note that if a RadioButton has an empty GroupName, then it is put
   into a group named after itself. So if RadioButton "A" has no
   GroupName, but RadioButton "B" has GroupName "A", then "it works",
   they are grouped.

   In dialogs, it is stored as a dlg:group-name attribute.

   In forms, it is stored as a form:group-name attribute.

Now, the problem that the reverted commit tried to fix is that in
ODF, form:group-name does not exist, but the grouping behaviour is
attached to form:name. RadioButtons that are supposed to be grouped
are supposed to have the same form:name. See
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-form_radio

Frankly, after giving it some thought and the difficulties it raises,
my first questions are:

1) Has _any_ implementation of ODF which implements forms *ever* done
   it this way, conforming to the standard?

2) If not, with some luck all implementations do it like we do, and
   then shall we consider adapting the standard to current behaviour
   for ODF 1.3 rather than shoehorning ourselves into a possibly badly
   designed corner of the standard?

About form:name see
http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1417450_253892949
It says:

 This may be used to give a form or control element an identity, which
 is can be used for scripting or for submitting the content of
 controls.

This clashes with the reuse of form:name that form:radio makes. If you
"force" several controls to have the same name, how are you *ever*
supposed to use the name "for scripting". You have just destroyed the
value of a name, which is getting the named thing so that you can
interrogate and manipulate it. I think that is a *bug* in the
standard.


What would it take to conform to the "form:radio" part of the standard
and still have a modicum of backwards compatibility? It seems obvious
to me that we have to decouple property names in our APIs and
attribute names in the XML.  Existing code must be able to continue
using properties "Name" and "GroupName" like it always did, and it
should work in the same way. The same for the "getByName" interface of
control containers.  But "Name" property should not necessarily go to
":name" attribute in the XML file.


In the case of RadioButtons, at least in forms, it is pretty clear
that the "GroupName" property would have to go to ":name"
attribute. We then need some other attribute to store the "Name"
property.

1) "form:id" is not acceptable, since form:id must be equal to an
   xml:id and xml:id has unicity requirement (across the whole XML
   document!) which "Name" does not currently have.

   Currently, form:id and xml:id are set as "control1", "control2",
   etc and are AFAIK not exposed in the API; I understand xml:id as
   *detail* of the *file* *format* (the serialisation), not part of
   the *data* *model*.

2) form:title is for a "tooltip" and what audio user agents are
   supposed to read. This seems not a good place for a "Name" there,
   more for a "Description". Plus I guess that this is where we
   already stick what the UI calls "Help text"?

3) We could stick it somewhere in form:properties.


*But* what bothers me is what should happen to other controls? Does
their "Name" still go in "form:name"? I'm unhappy about the difference
in treatment. If we follow for other controls the same as with
RadioButton, then what do we make of what other implementations put in
form:name? How do we allow, for interoperability with other
implementations, the user to *set* what is put in form:name?


I don't see any way to have good backwards (and hopefully forwards)
compatibility. Do you?

In my opinion, if we follow the "form:radio" part of the standard, we
don't follow (to the fullest) the "form:name" part of the standard.


Except for older versions (and forks) of the same codebase as us, what
other implementations do we need to interoperate with? What do *they*
do?

Once (if) we solve these issues, we can think about whether we align
Dialog RadioButton to the Forms behaviour or not.

-- 
Lionel