May I try to share a design that might be a bit more generic? Here is one
idea:

<field name="field1" search-group="group1"><text-find/></field>
<field name="field2" search-group="group1"><text-find/></field>
<field name="field3" search-group="group2"><text-find/></field>
<field name="field4" search-group="group2"><text-find/></field>

Then we change the find services so that each group "AND" its members and
the groups are "OR"ed together.

So in this example the find service would have the condition: (field1 AND
field2) OR (field3 AND field4)

I think this is simple enough but maybe provides more flexibility?

On Feb 2, 2018 4:22 PM, "gil portenseigne" <gil.portensei...@nereide.fr>
wrote:

I'll try to improve xml widget integration adding a field like :

<field name="field1" group-find-condition="unionKey"><text-find/></field>

WDYT ?



On 02/02/2018 14:16, gil portenseigne wrote:

> In a widget form to "OR" a condition between x fields you have to :
>
> <field name="field1"><text-find/></field>
> <field name="field1_grp"><hidden value="unionKey"/></field>
> <field name="field2"><text-find/></field>
> <field name="field2_grp"><hidden value="unionKey"/></field>
> <field name="field3"><text-find/></field>
> <field name="field3_grp"><hidden value="unionKey"/></field>
> <field name="field4"><text-find/></field>
> <field name="field4_grp"><hidden value="unionKey2"/></field>
> <field name="field5"><text-find/></field>
> <field name="field5_grp"><hidden value="unionKey2"/></field
> <field name="field6"><text-find/></field>
> <field name="field7"><text-find/></field>
>
> You'll get
>
> EntityCondition.makeCondition(
>     UtilMisc.toList(field1Condition, field2Condition, field3Condition),
> EntityOperator.OR)
>
> EntityCondition.makeCondition(
>     UtilMisc.toList(field4Condition, field5Condition), EntityOperator.OR)
>
> These will be "AND" with the others... (6 and 7)
>
> Indeed that's a bit ugly... but that do the job, and like I said, it's a
> pretty rare need.
>
>
> On 02/02/2018 12:14, Taher Alkhateeb wrote:
>
>> Oh okay I understand. Well .. in that case how do you "OR" conditions in
>> the form? Do you do it selectively or do you want all "OR" or all "AND"?
>>
>> On Feb 2, 2018 1:26 PM, "gil portenseigne" <gil.portensei...@nereide.fr>
>> wrote:
>>
>> Inline
>>>
>>>
>>> On 02/02/2018 11:04, Taher Alkhateeb wrote:
>>>
>>> So it's not some SQL union but rather just a simple "OR" instead of "AND"
>>>> for some conditions.
>>>>
>>>> Yes it's that simple, but between different fields.
>>>
>>> I was actually thinking of this problem recently but not only for two
>>>> options but rather multiple options.
>>>>
>>>> Nice, so we are not alone meeting this issue. This improvement allow the
>>> "OR" to be used between multiple (2 and more) fields conditions (even
>>> multi-select widget). I took 2 for the example, but you can defined many
>>> different groups, that can contains many fields.
>>>
>>> To be more specific, our drop-down form widgets have an attribute
>>>> "allow-multiple" or something like that which yields a list of values.
>>>> This
>>>> cannot be currently handled by performFind and the other related search
>>>> services.
>>>>
>>>> I confirm that performFind works with multi-select fields, if *no
>>> specific
>>> operator* is set :
>>>
>>> if(UtilValidate.isNotEmpty(UtilGenerics.toList(fieldValue))){
>>>                  fieldOp = EntityOperator.IN;
>>>              } else {
>>>                  fieldOp = EntityOperator.EQUALS;
>>>              }
>>>
>>> The condition will be  EntityCondition.makeCondition(myField,
>>> EntityOperator.IN, selectedValues)
>>>
>>>    So I think having an automatic "OR" on multiple dropdown values
>>>
>>>> is an important feature to implement and I would give that a +1.
>>>>
>>>> The improvement concern OR condition between differents fields :)
>>>
>>> Thanks !
>>>
>>> Gil
>>>
>>>
>>> On Feb 2, 2018 11:44 AM, "gil portenseigne" <gil.portensei...@nereide.fr
>>>> >
>>>> wrote:
>>>>
>>>> Yes, actually using form widget with performFind services do not offer a
>>>> way to union two search criteria.
>>>>
>>>> Exemple : i want to find all communicationEvent that are in Bounced
>>>> status
>>>> *or* that contains something in note field. (very specific, strange,
>>>> thats
>>>> why)
>>>>
>>>>
>>>> By default all search criteria are managed in EntityCondition like :
>>>>
>>>> List<EntityCondition> allDefaultSearchCriteria =
>>>> UtilMisc.toList(criteria1Condition, criteria2Condition ...);
>>>>
>>>> The resulting final condition would result as :
>>>> EntityCondition.makeCondition(allDefaultSearchCriteria,
>>>> EntityOperator.AND)
>>>>
>>>>
>>>> With the enhancement, by regrouping two fields with field1_grp =
>>>> 'groupKey'
>>>> and field2_grp = 'groupKey'
>>>>
>>>> the following condition is added to the other default ones like :
>>>>
>>>> allDefaultSearchCriteria.add(EntityCondition.makeCondition(U
>>>> tilMisc.toList(field1Condition, field2Condition), EntityOperator.OR));
>>>>
>>>> I hope this will be clearer.
>>>>
>>>>
>>>> On 01/02/2018 21:07, Taher Alkhateeb wrote:
>>>>
>>>> Hi, perhaps if you share the idea of how to translate it to the entity
>>>>
>>>>> engine conditions then we'd be better informed?
>>>>>
>>>>> On Feb 1, 2018 6:30 PM, "gil portenseigne" <
>>>>> gil.portensei...@nereide.fr>
>>>>> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> In a customer project we met a very specific need in a search screen
>>>>>> that
>>>>>> offer search criteria that must unions and not intersect.
>>>>>>
>>>>>> I propose this improvement in OFBIZ-10195, https://s.apache.org/sjW1
>>>>>> but
>>>>>> i'm wondering if any of you ever met such need ?
>>>>>>
>>>>>> Is that worth to be commited in the code base ? I tend to say yes, but
>>>>>> i'd
>>>>>> like to hear the community out about this.
>>>>>>
>>>>>> Thanks !
>>>>>>
>>>>>> Gil
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>

Reply via email to