Ajaxifying lookup fields

[Jacques Le Roux]

From: "David E Jones" <[hidden email]>

> On Nov 24, 2009, at 2:49 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <[hidden email]>
>>>
>>> On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote:
>>>
>>>> Hi Bilgin,
>>>>
>>>> Just one question
>>>> From: "Bilgin Ibryam" <[hidden email]>
>>>> [big snip]
>>>>>>>> 2.  There is no way of indicating what field you actually want to search against.
>>>>>>>
>>>>>>> This would typically be a search on whatever the description is made up of (ie that's what users expect).
>>>>> Searching on one field is not useful for most of the cases. For example to search for a party, it is good to search in
>>>>> partyId, firstName, middleName, lastName, groupName fields.
>>>>> With other entities it would be good to search at lease in ID and description fields.
>>>>
>>>> But partyId is unique, so searching on only one field makes sense, or ?
>>>
>>> A partial partyId isn't unique though...
>>
>> I don't get it, Party has only partyId as primary key, isn'it ?
>
> It depends on the UI. You can assume that what was entered was the complete value and requires an exact match, or a partial value
> and can match multiple records.
>
> For example: If you specify a partial value, like only 3 characters, and you have coded it to not assume those 3 characters are
> the entire PK value, then you can query for all PK values that include those 3 characters.
>
> -David

Ho I see now. I used something like that for the party search I recently wrote in POS (using a dynamic entity view) but not on PK
though (as Bilgin pointed out it would be almost useless for final users and POS is all about them)

Jacques

[Bilgin Ibryam-2]

> Hi Bilgin,
>
> Thanks for your comments, I'm not actually against your approach and
> think it is a good idea to reuse existing search functionalities.  
> I've had a quick look at your patch (finally) and I have to agree that
> you're solution is better than mine.  About the verbosity my inline
> event, I did that on purpose to show the concept in a single file, the
> actual intention is that you would call minilang or a service to
> process the event.  But anyway, there are a few things that I think we
> need to improve in your patch, I'll try and find some time tomorrow to
> gather my thoughts and put some comments in jira.
>
> Regards
> Scott

Hi Scott,

could you write down what needs to be improved in OFBIZ-3211 whenever
you got some free time. I'm planning to work on this issue these days.

Thanks
Bilgin

[Scott Gray-2]

On 19/12/2009, at 2:21 AM, Bilgin Ibryam wrote:

>
>> Hi Bilgin,
>>
>> Thanks for your comments, I'm not actually against your approach  
>> and think it is a good idea to reuse existing search  
>> functionalities.  I've had a quick look at your patch (finally) and  
>> I have to agree that you're solution is better than mine.  About  
>> the verbosity my inline event, I did that on purpose to show the  
>> concept in a single file, the actual intention is that you would  
>> call minilang or a service to process the event.  But anyway, there  
>> are a few things that I think we need to improve in your patch,  
>> I'll try and find some time tomorrow to gather my thoughts and put  
>> some comments in jira.
>>
>> Regards
>> Scott
> Hi Scott,
>
> could you write down what needs to be improved in OFBIZ-3211  
> whenever you got some free time. I'm planning to work on this issue  
> these days.
>

Looking at it now, sorry for the delay.

Regards
Scott