Le 11/12/2016 à 19:09, Jacques Le Roux a écrit :
Hi, [...]
we could simply allow also the 1st way (no map). It's not a big deal
to change in XSD and to document there. And I like it, because having
a default value is always welcome (conventions over configuration),
specially for lazy developers ;)
But it would be inconsistent with Minilang. My question: should we
allow both way in widgets actions and makes it different than in
Minilang? Note that another possibility is to also allow it in
Minilang but at 1st glance it entails more work...
Opinions?
I'm in favor to force the value-field attribute but the main problem
would be how ensure no regression on screen because set all fields
directly on context put a blur on the origin at rendering on form.
But on other way the element enty-and and entity-condition haven't the
list-name mandatory and resolve automatically "listIt" if not present.
So the proposal to set a default value for the value field seems to be a
good idea also but what default value ?
* context : with the currently risk to blur field origin
* context.lookupValue : and we can improve the model form renderer to
resolve fields value from parameter, context and lookupValue
* context.${lower_case:entityName} : more beautifull but not really easy
to implement some automation .
nicolas
Jacques
