[QUESTION] OFBIZ-7680

[Jacques Le Roux]

Hi,

OFBiz throws error message like <<Attribute 'value-field' must appear on element 'entity-one'>> when used in widget forms.
But it actually puts the Entity fields values directly in context, so something like

<actions>
     <entity-one entity-name="Content">
         <field-map field-name="contentId" from-field="contentId"/>
     </entity-one>
</actions>
<field name="contentId"><hidden/></field>

works since contentId is pushed into context.

Now the same does not exist in Minilang. Beside fixing the error message by using a map name in such cases like

<actions>
     <entity-one entity-name="Content"  value-field="content">
         <field-map field-name="contentId" from-field="contentId"/>
     </entity-one>
</actions>
<field name="content.contentId"><hidden/></field>

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?

Jacques

[Nicolas Malin-2]

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

[Jacques Le Roux]

Le 12/12/2016 à 09:23, Nicolas Malin a écrit :

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

Thanks Nicolas,

I was thinking as a default-value as it is now. I mean fields directly in context. But thinking about it this is dangerous because we can overwrite
existing values (even if this is a very low risk). I don't really like the idea of constructing a specific map because as you said it blurs things and
is inconsistent with Minilang. So finally, I think I was too lazy and the best solution is to enforce the rule to clearly define a map and have it
consistent with Minilang

Other opinions?

BTW enty-and and entity-condition resolving automatically to "listIt" if not present was IMO a good idea (convention over configuration) paving to hell.
I remember when I started with OFBiz "wondering" about that. But it's now a convention and I think nobody would want to change that?

Jacques

[Jacques Le Roux]

Le 12/12/2016 à 09:50, Jacques Le Roux a écrit :

> Le 12/12/2016 à 09:23, Nicolas Malin a écrit :
>> 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 .
> Thanks Nicolas,
>
> I was thinking as a default-value as it is now. I mean fields directly in context. But thinking about it this is dangerous because we can overwrite
> existing values (even if this is a very low risk). I don't really like the idea of constructing a specific map because as you said it blurs things
> and is inconsistent with Minilang. So finally, I think I was too lazy and the best solution is to enforce the rule to clearly define a map and have
> it consistent with Minilang
>
> Other opinions?
>
> BTW enty-and and entity-condition resolving automatically to "listIt" if not present was IMO a good idea (convention over configuration) paving to
> hell.
> I remember when I started with OFBiz "wondering" about that. But it's now a convention and I think nobody would want to change that?
>
> Jacques
>

To complete I must also say Nicolas's proposition seems much easier to implement and he has already proposed a patch for his 1st option at at OFBIZ-7680.
I did not check what enforcing the rule entails and as Nicolas said using context as map make treating legacy easier, but I think we should not be led
by legacy.

BTW, Nicolas, what do you envision as "regression on screen"? It's only a legacy issue on existing code (ie adding a value-field on entity-one and use
it as a map on fields), right?
We have not much to change OOTB, do you fear for custom projects? Do you think this "feature" is much used?

Jacques