You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Bilgin Ibryam <bi...@gmail.com> on 2009/11/17 15:17:38 UTC
Ajaxifying lookup fields
Hi all,
I'd like to propose a way to add ajax support for lookup fields.
For that purpose I created a small POC code, where you can test it
https://issues.apache.org/jira/browse/OFBIZ-3211
The idea is to add ajax autocompleter by default to all lookup fields
(generated from form widgets), which gets activated whenever the user
types some letters in the lookup field.
To retrieve the data is used the same url and screen as the lookup, but
with an extra parameter indicating that it is an ajax request.
Then on the server side, the only needed change is to add 4 lines of
code to each lookup screen which we want to have ajax support.
This extension doesn't affect the current usage of lookup button, which
still can be used for advanced searches.
There are still things to fix and tune up, but the code is stable enough
to see it in action.
To demonstrate that I added the 4 lines to LookupPartyName lookup
screen. So after applying the patch, you can go to any screen using
LookupPartyName lookup(this lookup is used in most of the party lookups,
like accounting-> invoices, payments) and type some letters in party id
fields.
I'd be glad to hear your opinion on this.
Regards,
Bilgin Ibryam
Re: Ajaxifying lookup fields
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
> 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
Re: Ajaxifying lookup fields
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 24/11/2009, at 10:31 PM, Bilgin Ibryam wrote:
[snippety-snip]
>> Well I'm saying it is easier to implement that an auto-complete
>> within a drop-down. In a way I guess it is similar to the on-field-
>> event-update-area element, but it is actually part of a larger POC
>> I've been working on from time to time whereby every field element
>> can have a field-events sub-element, whenever the event occurs the
>> actions are run and the result is sent back to the form. The main
>> differences are that you don't specify a target (because the event
>> is inline) and you don't specify an update area. The client-side
>> takes the json result and updates all necessary fields according to
>> a standard client-side form model.
>>
>>
>> Some examples of values you might choose to return:
>> (Substitute fieldName with the actual field-name)
>> fieldName.value (this could update a text input's value, a drop-
>> down selection, a hidden input value etc.)
>> fieldName.options (a list of value/description maps for updating a
>> drop-down's options e.g. select a country and the state list gets
>> repopulated)
>> fieldName.error (an error message perhaps after some server side
>> validation)
>> fieldName.disabled (boolean to disable a field e.g. perhaps a
>> submit button until some error is resolved)
>> fieldGroupId.hidden (boolean to show or hide a field group)
>>
>> I still don't have solid proposal in place really, just an idea of
>> what it might be nice to be able to support and possible way of
>> achieving it. I only started discussing the auto-complete portion
>> because of Bilgin's POC, I thought I better get my 2 cents in
>> before things headed in a different direction. But yes the main
>> differences between this and on-field-event-update-area is the
>> inline actions and the ability to update multiple "areas".
>>
> I liked very much the idea of inline events and the direction of
> this conversation, but as for the lookup autocompleter (which is the
> only target of my POC code), I think my solution fits betters. There
> are more than five hundred lookup fields in the project, and adding
> autocompleter code to each field(entity name to search in, fields to
> search, field(s) to return as result, there might be other options
> as well) plus the existing lookup code seems not feasible and would
> clutter the code. Also in lots of forms, there are more than one
> references to the same lookup (party name lookup) and this will end
> up in repeating code for the same autocompleter.
>
> On the other hand my solution doesn't require any change on the form
> field definitions. There is already a target specified for the
> lookup, and event (screen). So by adding 2 lines per lookup screen,
> it is possible to return a properly formated response to the
> autocompleter. And it will be more consistent to specify all the
> autocomplete options for a spcific lookup in one place.
>
> Even the autocompleter extension seems trivial, it reduces
> significantly the clicks while working with forms. If you want to
> see, I could commit it for a day, only for testing and then revert.
>
> Regards,
> Bilgin
>
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
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
Jacques Le Roux wrote:
> Hi Bilgin,
>
> Just one question
> From: "Bilgin Ibryam" <bi...@gmail.com>
> [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 ?
>
> Jacques
I suppose only ofbiz programmers know the data by Ids ;) For a user it
would be much easier to write part of the name of the customer (it could
be part of first, middle, last name, group name or part of the partyId)
and then see the matching records displayed in the autocompleter.
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
Jacques Le Roux wrote:
> Thanks for your answers Bilgin
>
>
>> Here is part of my first post in this thread: "I'd like to propose a
>> way to add ajax support for* *lookup* *fields**. For that purpose I
>> created a small POC code, where you can test it
>> https://issues.apache.org/jira/browse/OFBIZ-3211 "
>
> Sorry, I forgot about it
>
> Jacques
No problem Jacques. Now you can see it and give some feedback ;)
Bilgin
Re: Ajaxifying lookup fields
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for your answers Bilgin
From: "Bilgin Ibryam" <bi...@gmail.com>
> Jacques Le Roux wrote:
>>> Even the autocompleter extension seems trivial, it reduces
>>> significantly the clicks while working with forms. If you want to
>>> see, I could commit it for a day, only for testing and then revert.
>>
>> Then why not create a Jira (with maybe a link to this thread) ?
>>
>> Jacques
>>
>>> Regards,
>>> Bilgin
>>>
>>
> Here is part of my first post in this thread: "I'd like to propose a way
> to add ajax support for* *lookup* *fields**. For that purpose I created
> a small POC code, where you can test it
> https://issues.apache.org/jira/browse/OFBIZ-3211 "
Sorry, I forgot about it
Jacques
> Bilgin
>
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
Jacques Le Roux wrote:
>> Even the autocompleter extension seems trivial, it reduces
>> significantly the clicks while working with forms. If you want to
>> see, I could commit it for a day, only for testing and then revert.
>
> Then why not create a Jira (with maybe a link to this thread) ?
>
> Jacques
>
>> Regards,
>> Bilgin
>>
>
Here is part of my first post in this thread: "I'd like to propose a way
to add ajax support for* *lookup* *fields**. For that purpose I created
a small POC code, where you can test it
https://issues.apache.org/jira/browse/OFBIZ-3211 "
Bilgin
Re: Ajaxifying lookup fields
Posted by Jacques Le Roux <ja...@les7arts.com>.
> Even the autocompleter extension seems trivial, it reduces
> significantly the clicks while working with forms. If you want to see, I
> could commit it for a day, only for testing and then revert.
Then why not create a Jira (with maybe a link to this thread) ?
Jacques
> Regards,
> Bilgin
>
Re: Ajaxifying lookup fields
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
> On Nov 24, 2009, at 2:49 PM, Jacques Le Roux wrote:
>
>> From: "David E Jones" <de...@me.com>
>>>
>>> On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote:
>>>
>>>> Hi Bilgin,
>>>>
>>>> Just one question
>>>> From: "Bilgin Ibryam" <bi...@gmail.com>
>>>> [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
Re: Ajaxifying lookup fields
Posted by David E Jones <de...@me.com>.
On Nov 24, 2009, at 2:49 PM, Jacques Le Roux wrote:
> From: "David E Jones" <de...@me.com>
>>
>> On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote:
>>
>>> Hi Bilgin,
>>>
>>> Just one question
>>> From: "Bilgin Ibryam" <bi...@gmail.com>
>>> [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
Re: Ajaxifying lookup fields
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "David E Jones" <de...@me.com>
>
> On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote:
>
>> Hi Bilgin,
>>
>> Just one question
>> From: "Bilgin Ibryam" <bi...@gmail.com>
>> [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 ?
Jacques
> -David
>
Re: Ajaxifying lookup fields
Posted by David E Jones <de...@me.com>.
On Nov 24, 2009, at 3:51 AM, Jacques Le Roux wrote:
> Hi Bilgin,
>
> Just one question
> From: "Bilgin Ibryam" <bi...@gmail.com>
> [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...
-David
Re: Ajaxifying lookup fields
Posted by Jacques Le Roux <ja...@les7arts.com>.
Hi Bilgin,
Just one question
From: "Bilgin Ibryam" <bi...@gmail.com>
[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 ?
Jacques
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
Inline
> On 22/11/2009, at 5:03 PM, David E Jones wrote:
>
>>
>> On Nov 21, 2009, at 8:40 PM, Scott Gray wrote:
>>
>>> Hi David,
>>>
>>> I've looked at doing that a couple of times now but it usually ends
>>> up presenting a few difficulties for something that is seemingly
>>> simple:
>>> 1. You're stuck with either using entities or view entities, I
>>> guess you could use a predefined list but that would defeat the
>>> purpose somewhat. My example below is a little boring but one
>>> possibly common example of where you might need more power is an
>>> autocomplete for a party name that could be either person or party
>>> group where the results of two entities need to be combined. You
>>> could call a service to retrieve the list in my example.
>>
>> With most things that is the idea of the form widget, ie provide an
>> easy way to do the most common things (like lookup based on an entity
>> or view-entity, using any conditions specified plus the text
>> entered), and then have facilities for dropping down to scripting or
>> services or templates or whatever in order to be able to handle
>> anything so that the less common cases are still quite doable. Right
>> now the autocomplete implementation supports the less common cases
>> well, but is inefficient for the more simple and frequent stuff.
>
> As far as I know the existing auto-completer
> (on-field-event-update-area right?) remains unused OOTB, which I think
> may be a testament to how useful it is.
Agreed. The main reason for me was that I had to code also the event
separately, which means double work.
>>
>>> 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.
> What about a case like this:
> <field name="currencyUomId" title="${uiLabelMap.CommonCurrency}">
> <drop-down allow-empty="true"
> no-current-selected-key="${defaultOrganizationPartyCurrencyUomId}">
> <entity-options key-field-name="uomId"
> description="${description} - ${abbreviation}" entity-name="Uom">
> <entity-constraint name="uomTypeId"
> operator="equals" value="CURRENCY_MEASURE"/>
> <entity-order-by field-name="description"/>
> </entity-options>
> </drop-down>
> </field>
> The abbreviation is useful to display but not necessarily something
> you want to search against. And even if you did want to search
> against it how would you parse this string for a search?
>
>>
>>> 3. There seems to be a common trend with auto-completers that they
>>> can be paired with an additional lookup form to allow for an
>>> advanced search, adding this capability to the drop down element
>>> only makes sense for an auto-completer.
>>
>> Not sure what you mean by this... but it sounds interesting. Do you
>> mean something like a multi-field auto-completer?
>
> I mean you use a lookup form (like we do now with the lookup element)
> as a fall back when the user wants to do a more advanced search than
> what an auto-completer allows.
+ 1
>
>>
>>> In the end it seemed to me that while a drop-down and an
>>> auto-completer are quite similar, the differences between the two
>>> were enough to warrant a separate element (plus it's a damn sight
>>> easier :-)
>>
>> What you propose might be easier to implement, but wouldn't it be
>> pretty similar to what exists now... with the difference being you
>> can specify the event inline instead of coding it separately?
>
> Well I'm saying it is easier to implement that an auto-complete within
> a drop-down. In a way I guess it is similar to the
> on-field-event-update-area element, but it is actually part of a
> larger POC I've been working on from time to time whereby every field
> element can have a field-events sub-element, whenever the event occurs
> the actions are run and the result is sent back to the form. The main
> differences are that you don't specify a target (because the event is
> inline) and you don't specify an update area. The client-side takes
> the json result and updates all necessary fields according to a
> standard client-side form model.
>
>
> Some examples of values you might choose to return:
> (Substitute fieldName with the actual field-name)
> fieldName.value (this could update a text input's value, a drop-down
> selection, a hidden input value etc.)
> fieldName.options (a list of value/description maps for updating a
> drop-down's options e.g. select a country and the state list gets
> repopulated)
> fieldName.error (an error message perhaps after some server side
> validation)
> fieldName.disabled (boolean to disable a field e.g. perhaps a submit
> button until some error is resolved)
> fieldGroupId.hidden (boolean to show or hide a field group)
>
> I still don't have solid proposal in place really, just an idea of
> what it might be nice to be able to support and possible way of
> achieving it. I only started discussing the auto-complete portion
> because of Bilgin's POC, I thought I better get my 2 cents in before
> things headed in a different direction. But yes the main differences
> between this and on-field-event-update-area is the inline actions and
> the ability to update multiple "areas".
>
I liked very much the idea of inline events and the direction of this
conversation, but as for the lookup autocompleter (which is the only
target of my POC code), I think my solution fits betters. There are more
than five hundred lookup fields in the project, and adding autocompleter
code to each field(entity name to search in, fields to search, field(s)
to return as result, there might be other options as well) plus the
existing lookup code seems not feasible and would clutter the code. Also
in lots of forms, there are more than one references to the same lookup
(party name lookup) and this will end up in repeating code for the same
autocompleter.
On the other hand my solution doesn't require any change on the form
field definitions. There is already a target specified for the lookup,
and event (screen). So by adding 2 lines per lookup screen, it is
possible to return a properly formated response to the autocompleter.
And it will be more consistent to specify all the autocomplete options
for a spcific lookup in one place.
Even the autocompleter extension seems trivial, it reduces
significantly the clicks while working with forms. If you want to see, I
could commit it for a day, only for testing and then revert.
Regards,
Bilgin
Re: Ajaxifying lookup fields
Posted by Scott Gray <sc...@hotwaxmedia.com>.
On 22/11/2009, at 5:03 PM, David E Jones wrote:
>
> On Nov 21, 2009, at 8:40 PM, Scott Gray wrote:
>
>> Hi David,
>>
>> I've looked at doing that a couple of times now but it usually ends
>> up presenting a few difficulties for something that is seemingly
>> simple:
>> 1. You're stuck with either using entities or view entities, I
>> guess you could use a predefined list but that would defeat the
>> purpose somewhat. My example below is a little boring but one
>> possibly common example of where you might need more power is an
>> autocomplete for a party name that could be either person or party
>> group where the results of two entities need to be combined. You
>> could call a service to retrieve the list in my example.
>
> With most things that is the idea of the form widget, ie provide an
> easy way to do the most common things (like lookup based on an
> entity or view-entity, using any conditions specified plus the text
> entered), and then have facilities for dropping down to scripting or
> services or templates or whatever in order to be able to handle
> anything so that the less common cases are still quite doable. Right
> now the autocomplete implementation supports the less common cases
> well, but is inefficient for the more simple and frequent stuff.
As far as I know the existing auto-completer (on-field-event-update-
area right?) remains unused OOTB, which I think may be a testament to
how useful it is. It's been a long time since I looked at it though
so I'm not really in a position to critique it further.
>
>> 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).
What about a case like this:
<field name="currencyUomId" title="$
{uiLabelMap.CommonCurrency}">
<drop-down allow-empty="true" no-current-selected-key="$
{defaultOrganizationPartyCurrencyUomId}">
<entity-options key-field-name="uomId" description="$
{description} - ${abbreviation}" entity-name="Uom">
<entity-constraint name="uomTypeId"
operator="equals" value="CURRENCY_MEASURE"/>
<entity-order-by field-name="description"/>
</entity-options>
</drop-down>
</field>
The abbreviation is useful to display but not necessarily something
you want to search against. And even if you did want to search
against it how would you parse this string for a search?
>
>> 3. There seems to be a common trend with auto-completers that they
>> can be paired with an additional lookup form to allow for an
>> advanced search, adding this capability to the drop down element
>> only makes sense for an auto-completer.
>
> Not sure what you mean by this... but it sounds interesting. Do you
> mean something like a multi-field auto-completer?
I mean you use a lookup form (like we do now with the lookup element)
as a fall back when the user wants to do a more advanced search than
what an auto-completer allows.
>
>> In the end it seemed to me that while a drop-down and an auto-
>> completer are quite similar, the differences between the two were
>> enough to warrant a separate element (plus it's a damn sight
>> easier :-)
>
> What you propose might be easier to implement, but wouldn't it be
> pretty similar to what exists now... with the difference being you
> can specify the event inline instead of coding it separately?
Well I'm saying it is easier to implement that an auto-complete within
a drop-down. In a way I guess it is similar to the on-field-event-
update-area element, but it is actually part of a larger POC I've been
working on from time to time whereby every field element can have a
field-events sub-element, whenever the event occurs the actions are
run and the result is sent back to the form. The main differences are
that you don't specify a target (because the event is inline) and you
don't specify an update area. The client-side takes the json result
and updates all necessary fields according to a standard client-side
form model.
Some examples of values you might choose to return:
(Substitute fieldName with the actual field-name)
fieldName.value (this could update a text input's value, a drop-down
selection, a hidden input value etc.)
fieldName.options (a list of value/description maps for updating a
drop-down's options e.g. select a country and the state list gets
repopulated)
fieldName.error (an error message perhaps after some server side
validation)
fieldName.disabled (boolean to disable a field e.g. perhaps a submit
button until some error is resolved)
fieldGroupId.hidden (boolean to show or hide a field group)
I still don't have solid proposal in place really, just an idea of
what it might be nice to be able to support and possible way of
achieving it. I only started discussing the auto-complete portion
because of Bilgin's POC, I thought I better get my 2 cents in before
things headed in a different direction. But yes the main differences
between this and on-field-event-update-area is the inline actions and
the ability to update multiple "areas".
Regards
Scott
>
> -David
>
>
>> On 22/11/2009, at 3:56 PM, David E Jones wrote:
>>
>>>
>>> Why not just use the existing drop-down sub-elements to populate
>>> the auto-complete drop-down. That has actually been my intention
>>> to implement, then an autocomplete drop-down could be implemented
>>> with a flag on the existing drop-down element, or with a new field
>>> sub-element which would use the same sub-elements as the drop-down
>>> element.
>>>
>>> I don't like the currently implemented form that requires you to
>>> implement an event that runs on the server in addition to defining
>>> the form field. Really with the information in the existing drop-
>>> down element you have all of the parameterization you need to
>>> implement a generic event on the server that could do a lookup
>>> based on the sub-elements of drop-down plus the characters that
>>> have been entered so far.
>>>
>>> -David
>>>
>>>
>>> On Nov 17, 2009, at 2:33 PM, Scott Gray wrote:
>>>
>>>> Hi Bilgin,
>>>>
>>>> Sounds interesting I'll be sure to take a look within the next
>>>> few days.
>>>>
>>>> As coincidences would have it I've also been working on a POC for
>>>> ajax autocompletion which takes a different approach. I'm not
>>>> done yet but should hopefully have something this weekend.
>>>> The form definition would look like this:
>>>> <field name="country>
>>>> <autocompleter result-field="countries" result-value-name="geoId"
>>>> result-description-name="geoName">
>>>> <field-event>
>>>> <set field="geoName" value="${parameters.country}%"/>
>>>> <entity-condition entity-name="Geo" list="countries">
>>>> <condition-list>
>>>> <condition-expr field-name="geoName" operator="like" from-
>>>> field="geoName" ignore-case="true"/>
>>>> <condition-expr field-name="geoTypeId" value="COUNTRY"/>
>>>> </condition-list>
>>>> <order-by field-name="geoName"/>
>>>> </entity-condition>
>>>> </field-event>
>>>> </autcompleter>
>>>> </field>
>>>>
>>>> The field-event is then stored in the session and accessed via a
>>>> generic request which runs the actions and returns a json
>>>> result. The field-event tag allows the same elements as the
>>>> actions and row-actions element so you can call scripts or
>>>> services or whatever so long as at the end of it the field
>>>> specified by result-field contains a list of maps.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>> On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'd like to propose a way to add ajax support for lookup fields.
>>>>> For that purpose I created a small POC code, where you can test
>>>>> it https://issues.apache.org/jira/browse/OFBIZ-3211
>>>>>
>>>>> The idea is to add ajax autocompleter by default to all lookup
>>>>> fields (generated from form widgets), which gets activated
>>>>> whenever the user types some letters in the lookup field.
>>>>> To retrieve the data is used the same url and screen as the
>>>>> lookup, but with an extra parameter indicating that it is an
>>>>> ajax request.
>>>>>
>>>>> Then on the server side, the only needed change is to add 4
>>>>> lines of code to each lookup screen which we want to have ajax
>>>>> support.
>>>>> This extension doesn't affect the current usage of lookup
>>>>> button, which still can be used for advanced searches.
>>>>>
>>>>> There are still things to fix and tune up, but the code is
>>>>> stable enough to see it in action.
>>>>> To demonstrate that I added the 4 lines to LookupPartyName
>>>>> lookup screen. So after applying the patch, you can go to any
>>>>> screen using LookupPartyName lookup(this lookup is used in most
>>>>> of the party lookups, like accounting-> invoices, payments) and
>>>>> type some letters in party id fields.
>>>>> I'd be glad to hear your opinion on this.
>>>>>
>>>>> Regards,
>>>>> Bilgin Ibryam
>>>>
>>>
>>
>
Re: Ajaxifying lookup fields
Posted by David E Jones <de...@me.com>.
On Nov 21, 2009, at 8:40 PM, Scott Gray wrote:
> Hi David,
>
> I've looked at doing that a couple of times now but it usually ends
> up presenting a few difficulties for something that is seemingly
> simple:
> 1. You're stuck with either using entities or view entities, I
> guess you could use a predefined list but that would defeat the
> purpose somewhat. My example below is a little boring but one
> possibly common example of where you might need more power is an
> autocomplete for a party name that could be either person or party
> group where the results of two entities need to be combined. You
> could call a service to retrieve the list in my example.
With most things that is the idea of the form widget, ie provide an
easy way to do the most common things (like lookup based on an entity
or view-entity, using any conditions specified plus the text entered),
and then have facilities for dropping down to scripting or services or
templates or whatever in order to be able to handle anything so that
the less common cases are still quite doable. Right now the
autocomplete implementation supports the less common cases well, but
is inefficient for the more simple and frequent stuff.
> 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).
> 3. There seems to be a common trend with auto-completers that they
> can be paired with an additional lookup form to allow for an
> advanced search, adding this capability to the drop down element
> only makes sense for an auto-completer.
Not sure what you mean by this... but it sounds interesting. Do you
mean something like a multi-field auto-completer?
> In the end it seemed to me that while a drop-down and an auto-
> completer are quite similar, the differences between the two were
> enough to warrant a separate element (plus it's a damn sight
> easier :-)
What you propose might be easier to implement, but wouldn't it be
pretty similar to what exists now... with the difference being you can
specify the event inline instead of coding it separately?
-David
> On 22/11/2009, at 3:56 PM, David E Jones wrote:
>
>>
>> Why not just use the existing drop-down sub-elements to populate
>> the auto-complete drop-down. That has actually been my intention to
>> implement, then an autocomplete drop-down could be implemented with
>> a flag on the existing drop-down element, or with a new field sub-
>> element which would use the same sub-elements as the drop-down
>> element.
>>
>> I don't like the currently implemented form that requires you to
>> implement an event that runs on the server in addition to defining
>> the form field. Really with the information in the existing drop-
>> down element you have all of the parameterization you need to
>> implement a generic event on the server that could do a lookup
>> based on the sub-elements of drop-down plus the characters that
>> have been entered so far.
>>
>> -David
>>
>>
>> On Nov 17, 2009, at 2:33 PM, Scott Gray wrote:
>>
>>> Hi Bilgin,
>>>
>>> Sounds interesting I'll be sure to take a look within the next few
>>> days.
>>>
>>> As coincidences would have it I've also been working on a POC for
>>> ajax autocompletion which takes a different approach. I'm not
>>> done yet but should hopefully have something this weekend.
>>> The form definition would look like this:
>>> <field name="country>
>>> <autocompleter result-field="countries" result-value-name="geoId"
>>> result-description-name="geoName">
>>> <field-event>
>>> <set field="geoName" value="${parameters.country}%"/>
>>> <entity-condition entity-name="Geo" list="countries">
>>> <condition-list>
>>> <condition-expr field-name="geoName" operator="like" from-
>>> field="geoName" ignore-case="true"/>
>>> <condition-expr field-name="geoTypeId" value="COUNTRY"/>
>>> </condition-list>
>>> <order-by field-name="geoName"/>
>>> </entity-condition>
>>> </field-event>
>>> </autcompleter>
>>> </field>
>>>
>>> The field-event is then stored in the session and accessed via a
>>> generic request which runs the actions and returns a json result.
>>> The field-event tag allows the same elements as the actions and
>>> row-actions element so you can call scripts or services or
>>> whatever so long as at the end of it the field specified by result-
>>> field contains a list of maps.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'd like to propose a way to add ajax support for lookup fields.
>>>> For that purpose I created a small POC code, where you can test
>>>> it https://issues.apache.org/jira/browse/OFBIZ-3211
>>>>
>>>> The idea is to add ajax autocompleter by default to all lookup
>>>> fields (generated from form widgets), which gets activated
>>>> whenever the user types some letters in the lookup field.
>>>> To retrieve the data is used the same url and screen as the
>>>> lookup, but with an extra parameter indicating that it is an ajax
>>>> request.
>>>>
>>>> Then on the server side, the only needed change is to add 4 lines
>>>> of code to each lookup screen which we want to have ajax support.
>>>> This extension doesn't affect the current usage of lookup button,
>>>> which still can be used for advanced searches.
>>>>
>>>> There are still things to fix and tune up, but the code is stable
>>>> enough to see it in action.
>>>> To demonstrate that I added the 4 lines to LookupPartyName lookup
>>>> screen. So after applying the patch, you can go to any screen
>>>> using LookupPartyName lookup(this lookup is used in most of the
>>>> party lookups, like accounting-> invoices, payments) and type
>>>> some letters in party id fields.
>>>> I'd be glad to hear your opinion on this.
>>>>
>>>> Regards,
>>>> Bilgin Ibryam
>>>
>>
>
Re: Ajaxifying lookup fields
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi David,
I've looked at doing that a couple of times now but it usually ends up
presenting a few difficulties for something that is seemingly simple:
1. You're stuck with either using entities or view entities, I guess
you could use a predefined list but that would defeat the purpose
somewhat. My example below is a little boring but one possibly common
example of where you might need more power is an autocomplete for a
party name that could be either person or party group where the
results of two entities need to be combined. You could call a service
to retrieve the list in my example.
2. There is no way of indicating what field you actually want to
search against.
3. There seems to be a common trend with auto-completers that they
can be paired with an additional lookup form to allow for an advanced
search, adding this capability to the drop down element only makes
sense for an auto-completer.
In the end it seemed to me that while a drop-down and an auto-
completer are quite similar, the differences between the two were
enough to warrant a separate element (plus it's a damn sight easier :-)
Regards
Scott
On 22/11/2009, at 3:56 PM, David E Jones wrote:
>
> Why not just use the existing drop-down sub-elements to populate the
> auto-complete drop-down. That has actually been my intention to
> implement, then an autocomplete drop-down could be implemented with
> a flag on the existing drop-down element, or with a new field sub-
> element which would use the same sub-elements as the drop-down
> element.
>
> I don't like the currently implemented form that requires you to
> implement an event that runs on the server in addition to defining
> the form field. Really with the information in the existing drop-
> down element you have all of the parameterization you need to
> implement a generic event on the server that could do a lookup based
> on the sub-elements of drop-down plus the characters that have been
> entered so far.
>
> -David
>
>
> On Nov 17, 2009, at 2:33 PM, Scott Gray wrote:
>
>> Hi Bilgin,
>>
>> Sounds interesting I'll be sure to take a look within the next few
>> days.
>>
>> As coincidences would have it I've also been working on a POC for
>> ajax autocompletion which takes a different approach. I'm not done
>> yet but should hopefully have something this weekend.
>> The form definition would look like this:
>> <field name="country>
>> <autocompleter result-field="countries" result-value-name="geoId"
>> result-description-name="geoName">
>> <field-event>
>> <set field="geoName" value="${parameters.country}%"/>
>> <entity-condition entity-name="Geo" list="countries">
>> <condition-list>
>> <condition-expr field-name="geoName" operator="like" from-
>> field="geoName" ignore-case="true"/>
>> <condition-expr field-name="geoTypeId" value="COUNTRY"/>
>> </condition-list>
>> <order-by field-name="geoName"/>
>> </entity-condition>
>> </field-event>
>> </autcompleter>
>> </field>
>>
>> The field-event is then stored in the session and accessed via a
>> generic request which runs the actions and returns a json result.
>> The field-event tag allows the same elements as the actions and row-
>> actions element so you can call scripts or services or whatever so
>> long as at the end of it the field specified by result-field
>> contains a list of maps.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
>>
>>> Hi all,
>>>
>>> I'd like to propose a way to add ajax support for lookup fields.
>>> For that purpose I created a small POC code, where you can test it https://issues.apache.org/jira/browse/OFBIZ-3211
>>>
>>> The idea is to add ajax autocompleter by default to all lookup
>>> fields (generated from form widgets), which gets activated
>>> whenever the user types some letters in the lookup field.
>>> To retrieve the data is used the same url and screen as the
>>> lookup, but with an extra parameter indicating that it is an ajax
>>> request.
>>>
>>> Then on the server side, the only needed change is to add 4 lines
>>> of code to each lookup screen which we want to have ajax support.
>>> This extension doesn't affect the current usage of lookup button,
>>> which still can be used for advanced searches.
>>>
>>> There are still things to fix and tune up, but the code is stable
>>> enough to see it in action.
>>> To demonstrate that I added the 4 lines to LookupPartyName lookup
>>> screen. So after applying the patch, you can go to any screen
>>> using LookupPartyName lookup(this lookup is used in most of the
>>> party lookups, like accounting-> invoices, payments) and type some
>>> letters in party id fields.
>>> I'd be glad to hear your opinion on this.
>>>
>>> Regards,
>>> Bilgin Ibryam
>>
>
Re: Ajaxifying lookup fields
Posted by David E Jones <de...@me.com>.
Why not just use the existing drop-down sub-elements to populate the
auto-complete drop-down. That has actually been my intention to
implement, then an autocomplete drop-down could be implemented with a
flag on the existing drop-down element, or with a new field sub-
element which would use the same sub-elements as the drop-down element.
I don't like the currently implemented form that requires you to
implement an event that runs on the server in addition to defining the
form field. Really with the information in the existing drop-down
element you have all of the parameterization you need to implement a
generic event on the server that could do a lookup based on the sub-
elements of drop-down plus the characters that have been entered so far.
-David
On Nov 17, 2009, at 2:33 PM, Scott Gray wrote:
> Hi Bilgin,
>
> Sounds interesting I'll be sure to take a look within the next few
> days.
>
> As coincidences would have it I've also been working on a POC for
> ajax autocompletion which takes a different approach. I'm not done
> yet but should hopefully have something this weekend.
> The form definition would look like this:
> <field name="country>
> <autocompleter result-field="countries" result-value-name="geoId"
> result-description-name="geoName">
> <field-event>
> <set field="geoName" value="${parameters.country}%"/>
> <entity-condition entity-name="Geo" list="countries">
> <condition-list>
> <condition-expr field-name="geoName" operator="like" from-
> field="geoName" ignore-case="true"/>
> <condition-expr field-name="geoTypeId" value="COUNTRY"/>
> </condition-list>
> <order-by field-name="geoName"/>
> </entity-condition>
> </field-event>
> </autcompleter>
> </field>
>
> The field-event is then stored in the session and accessed via a
> generic request which runs the actions and returns a json result.
> The field-event tag allows the same elements as the actions and row-
> actions element so you can call scripts or services or whatever so
> long as at the end of it the field specified by result-field
> contains a list of maps.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
>
>> Hi all,
>>
>> I'd like to propose a way to add ajax support for lookup fields.
>> For that purpose I created a small POC code, where you can test it https://issues.apache.org/jira/browse/OFBIZ-3211
>>
>> The idea is to add ajax autocompleter by default to all lookup
>> fields (generated from form widgets), which gets activated whenever
>> the user types some letters in the lookup field.
>> To retrieve the data is used the same url and screen as the lookup,
>> but with an extra parameter indicating that it is an ajax request.
>>
>> Then on the server side, the only needed change is to add 4 lines
>> of code to each lookup screen which we want to have ajax support.
>> This extension doesn't affect the current usage of lookup button,
>> which still can be used for advanced searches.
>>
>> There are still things to fix and tune up, but the code is stable
>> enough to see it in action.
>> To demonstrate that I added the 4 lines to LookupPartyName lookup
>> screen. So after applying the patch, you can go to any screen using
>> LookupPartyName lookup(this lookup is used in most of the party
>> lookups, like accounting-> invoices, payments) and type some
>> letters in party id fields.
>> I'd be glad to hear your opinion on this.
>>
>> Regards,
>> Bilgin Ibryam
>
Re: Ajaxifying lookup fields
Posted by Bilgin Ibryam <bi...@gmail.com>.
Scott Gray wrote:
> Hi Bilgin,
>
> Sounds interesting I'll be sure to take a look within the next few days.
>
> As coincidences would have it I've also been working on a POC for ajax
> autocompletion which takes a different approach. I'm not done yet but
> should hopefully have something this weekend.
> The form definition would look like this:
> <field name="country>
> <autocompleter result-field="countries" result-value-name="geoId"
> result-description-name="geoName">
> <field-event>
> <set field="geoName" value="${parameters.country}%"/>
> <entity-condition entity-name="Geo" list="countries">
> <condition-list>
> <condition-expr field-name="geoName" operator="like"
> from-field="geoName" ignore-case="true"/>
> <condition-expr field-name="geoTypeId" value="COUNTRY"/>
> </condition-list>
> <order-by field-name="geoName"/>
> </entity-condition>
> </field-event>
> </autcompleter>
> </field>
>
> The field-event is then stored in the session and accessed via a
> generic request which runs the actions and returns a json result. The
> field-event tag allows the same elements as the actions and
> row-actions element so you can call scripts or services or whatever so
> long as at the end of it the field specified by result-field contains
> a list of maps.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
Hi Scott,
I like very much your idea about storing part of the widget logic in
session and accessing through ajax. I can't wait to see some code.
I think your idea would open a new area to extend the widgets to. Making
the more widgets dynamic at run time, would be a great benefit for the
project.
BTW, the proposal I did, uses only exiting ajax capabilities of the
widgets and server side.
Regards,
Bilgin
Re: Ajaxifying lookup fields
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Bilgin,
Sounds interesting I'll be sure to take a look within the next few days.
As coincidences would have it I've also been working on a POC for ajax
autocompletion which takes a different approach. I'm not done yet but
should hopefully have something this weekend.
The form definition would look like this:
<field name="country>
<autocompleter result-field="countries" result-value-name="geoId"
result-description-name="geoName">
<field-event>
<set field="geoName" value="${parameters.country}%"/>
<entity-condition entity-name="Geo" list="countries">
<condition-list>
<condition-expr field-name="geoName" operator="like" from-
field="geoName" ignore-case="true"/>
<condition-expr field-name="geoTypeId" value="COUNTRY"/>
</condition-list>
<order-by field-name="geoName"/>
</entity-condition>
</field-event>
</autcompleter>
</field>
The field-event is then stored in the session and accessed via a
generic request which runs the actions and returns a json result. The
field-event tag allows the same elements as the actions and row-
actions element so you can call scripts or services or whatever so
long as at the end of it the field specified by result-field contains
a list of maps.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:
> Hi all,
>
> I'd like to propose a way to add ajax support for lookup fields.
> For that purpose I created a small POC code, where you can test it https://issues.apache.org/jira/browse/OFBIZ-3211
>
> The idea is to add ajax autocompleter by default to all lookup
> fields (generated from form widgets), which gets activated whenever
> the user types some letters in the lookup field.
> To retrieve the data is used the same url and screen as the lookup,
> but with an extra parameter indicating that it is an ajax request.
>
> Then on the server side, the only needed change is to add 4 lines of
> code to each lookup screen which we want to have ajax support.
> This extension doesn't affect the current usage of lookup button,
> which still can be used for advanced searches.
>
> There are still things to fix and tune up, but the code is stable
> enough to see it in action.
> To demonstrate that I added the 4 lines to LookupPartyName lookup
> screen. So after applying the patch, you can go to any screen using
> LookupPartyName lookup(this lookup is used in most of the party
> lookups, like accounting-> invoices, payments) and type some letters
> in party id fields.
> I'd be glad to hear your opinion on this.
>
> Regards,
> Bilgin Ibryam
Re: Ajaxifying lookup fields
Posted by Pierre Smits <pi...@gmail.com>.
+1.
Will look at patch.
Regards,
Pierre
2009/11/17 Divesh Dutta <di...@hotwaxmedia.com>
> Hello Bilgin,
>
> This is great idea, and this will be very nice feature in OFBiz. I will
> surely give a try to your patch as soon as possible.
>
> Thanks
> --
> Divesh Dutta.
>
>
>
> Bilgin Ibryam wrote:
>
>> Hi all,
>>
>> I'd like to propose a way to add ajax support for lookup fields.
>> For that purpose I created a small POC code, where you can test it
>> https://issues.apache.org/jira/browse/OFBIZ-3211
>>
>> The idea is to add ajax autocompleter by default to all lookup fields
>> (generated from form widgets), which gets activated whenever the user types
>> some letters in the lookup field.
>> To retrieve the data is used the same url and screen as the lookup, but
>> with an extra parameter indicating that it is an ajax request.
>>
>> Then on the server side, the only needed change is to add 4 lines of code
>> to each lookup screen which we want to have ajax support.
>> This extension doesn't affect the current usage of lookup button, which
>> still can be used for advanced searches.
>>
>> There are still things to fix and tune up, but the code is stable enough
>> to see it in action.
>> To demonstrate that I added the 4 lines to LookupPartyName lookup screen.
>> So after applying the patch, you can go to any screen using LookupPartyName
>> lookup(this lookup is used in most of the party lookups, like accounting->
>> invoices, payments) and type some letters in party id fields. I'd be glad
>> to hear your opinion on this.
>>
>> Regards,
>> Bilgin Ibryam
>>
>
>
Re: Ajaxifying lookup fields
Posted by Divesh Dutta <di...@hotwaxmedia.com>.
Hello Bilgin,
This is great idea, and this will be very nice feature in OFBiz. I will
surely give a try to your patch as soon as possible.
Thanks
--
Divesh Dutta.
Bilgin Ibryam wrote:
> Hi all,
>
> I'd like to propose a way to add ajax support for lookup fields.
> For that purpose I created a small POC code, where you can test it
> https://issues.apache.org/jira/browse/OFBIZ-3211
>
> The idea is to add ajax autocompleter by default to all lookup fields
> (generated from form widgets), which gets activated whenever the user
> types some letters in the lookup field.
> To retrieve the data is used the same url and screen as the lookup,
> but with an extra parameter indicating that it is an ajax request.
>
> Then on the server side, the only needed change is to add 4 lines of
> code to each lookup screen which we want to have ajax support.
> This extension doesn't affect the current usage of lookup button,
> which still can be used for advanced searches.
>
> There are still things to fix and tune up, but the code is stable
> enough to see it in action.
> To demonstrate that I added the 4 lines to LookupPartyName lookup
> screen. So after applying the patch, you can go to any screen using
> LookupPartyName lookup(this lookup is used in most of the party
> lookups, like accounting-> invoices, payments) and type some letters
> in party id fields.
> I'd be glad to hear your opinion on this.
>
> Regards,
> Bilgin Ibryam