ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Malin <nicolas.ma...@nereide.fr>
Subject Re: [QUESTION] OFBIZ-7680
Date Mon, 12 Dec 2016 08:23:47 GMT


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
>
>


Mime
View raw message