minutes of ESC call ...

[Lionel Elie Mamane]

On Thu, Apr 18, 2013 at 03:54:19PM +0100, Michael Meeks wrote:

> * Scripting interface for form elements broken (?) (Lionel)

> 	+ I've just sent a message to the dev ML with subject
> 	  "Value of a ListBox, FMC paradigm for Form elements (controls)"

> 	+ C++ module / forms / frm::
> 		+ not only used by 'base'

> 	  In short:
> 	   1) our scripting (UNO) interface to form elements (controls)
> 	   sucks. It exposes the models, but the models don't have a
> 	   getCurrentController() and the control(ler) exposes useful APIs
> 	   that are thus NOT REACHABLE.
> 		+ getView returns the same object as the controller
> AI:		+ get a second view on what's up (Stephan)

As explained in the other thread, there is a somewhat roundabout way
to get the view/controller when one has the model, so it is not as bad
as I said, and is workable.

> 	   2) ListBox has the wrong notion of "current value". Change it to
> 	   the right one incompatibly? Add a new "current *bound* value"
> 	   notion to stay compatible, but make the interesting thing
> 	   accessible in some way?
> 		+ has two lists of key/values pairs.
> 		+ with a one-to-one mapping between the two,
> 		+ values that are displayed; and another that is written.
> 		+ getCurrentValue - shouldn't return string displayed,
> 		  but the value
> 		+ on a date-field; don't get Mon/1st/Jan - but an abstract date.
> 		+ not so clear as all that (Norbert/Eike)
> 		+ value written to field, not exposed at all (Lionel)
> 		+ API is a special exception for this box
> 			+ been there for a while.
> 		+ keeping back-compat there is important (Eike)
> 			+ introduce a new method - getActualCurrentValue
> 			+ or incompatibly extend the existing interface
> 			+ can we put it in a property instead ?

As I wrote on the other thread, getCurrentValue is part of the
interface meant to be used by validators.
http://api.libreoffice.org/docs/common/ref/com/sun/star/form/validation/XValidatableFormComponent.html

That is, a procedure that, given a value for the control says one of:

 - yes, accept that value (and eventually write it to the database)
 - no, reject that value with this error message
   (and force the user to change it or cancel his/her changes)

To me, it is craziness that the validator is supposed to operate on a
different value than what will be written out, so I changed it over
Norbert & Eike's objections. If having read this email the ESC still
disagrees with me, we'll see what we can do (in terms of
implementation, to revert only that change without breaking the other
improvements I did).

I *also* added new properties SelectedValue and SelectedValues to
access the values of the selected entries.

I updated the "External Value Binding" mechanism for ListBox
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/External_Value_Suppliers
http://wiki.openoffice.org/wiki/Documentation/DevGuide/Forms/Value_Bindings

It is a mechanism that is supposed to generalise the concept of
linking controls to database data; they are linked to an arbitrary
data supplier / sink through an UNO interface. I could do this in a
mostly backwards compatible way, because it was already the case that
what the external value binding gets depends on the type it
supports... The values are served as another type (namely Any) than
indices or display strings.

Note that it was already the case that when an external value binding
installs itself as validator, the value passed to the validator was
tweaked to match what was served to the external value binding. In
support of my position "the validator should get the same value as
what is written out".

-- 
Lionel