Objectlib: Add special constraint for named lookups.

[GoogleCodeExporter]

Constraints in the object library is currently only reading and validating 
data. In some cases you want to read data as a string, do some conversion and 
store it as a number or something else.

This can be achieved by attaching a special constraint to a string key where 
the constraint handler will be able to validate the string (possibly by 
delegating it to a user defined lookup callback), and convert it (also a 
callback). It might also be easier to just let the user do everything in the 
handler; validate, convert and store.

It's already possible for named lookups through custom constraints, but the 
user must write that code in the validation callback. Gotta figure out a 
balance between delegation and stock objectlib logic to avoid duplicated code. 
This constraint can't know which strings that are valid, but may receive an 
array with valid words for instance.

Note: Be aware of infinite recursion. When the constraint handler sets the 
converted value, constraints will be validated again. Maybe some tricks with a 
static variable might work where it sets a global flag (for that constraint 
type) to skip validation. Since it's single threaded it will work as long as 
the constraint handler doesn't set data in another key with the same constraint 
type. Need to figure out something clever here.

Original issue reported on code.google.com by richard.helgeby@gmail.com on 21 Apr 2013 at 1:42

[GoogleCodeExporter]

Constraint handler re-entry is prevented by using a global flag for each 
handler. When called, it reads the flag and says the value is valid if it's 
set. If not it sets the flag and reset it right before returning.

Since a constraint handler now may override the value being set, the user must 
be able to tell if something was set when calling a ObjLib_SetString function 
for instance.

The handlers only return whether the value is valid or not, and the set 
accessor functions return whether something was set according to this.

If the constraint handler says the value is valid, the accessor function store 
it in the object. But if the constraint handler want to override the value it 
has to prevent this from happening. The flags mentioned above should do this.

For instance, a key is internally stored as a cell and a string in a config 
file.
1. The keyvalue parser reads the constraint for that key and see that a string 
it should convert a string.
2. The string value is passed to the constraint handler, converted and then 
stored as a number using a SetCell-function.
3. The accessor function calls the constraint handler (which is this special 
converting handler). The handler returns immediately because it's already 
handling a constraint for that key (from step 2).
4. The handler in step 2 must return true because the value was valid.
5. The accessor function incorrectly writes the string since the value is valid.

The return value from contraint handlers now needs to be something like: valid, 
overridden, not valid. An enum seems to be perfect in this case.

Original comment by richard.helgeby@gmail.com on 22 Apr 2013 at 9:32

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Typo on step 1. This is the correct one:

1. The keyvalue parser reads the constraint for that key and see that it should 
convert a string.

(Issue comments needs an edit button!)

Original comment by richard.helgeby@gmail.com on 22 Apr 2013 at 9:36

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Added in projectcomponents:7b6fc6c411dd (191).

Original comment by richard.helgeby@gmail.com on 11 May 2013 at 12:27

• Changed state: Completed
• Added labels: ****
• Removed labels: ****