Re: Ajaxifying lookup fields

[Scott Gray]

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:

                    <entity-order-by field-name="description"/>
                </entity-options>
            </drop-down>
        </field>

<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"/> 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?

Some examples of values you might choose to return:
(Substitute fieldName with the actual field-name)

fieldGroupId.hidden (boolean to show or hide a field group)



Regards
Scott

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

-David

On 22/11/2009, at 3:56 PM, David E Jones wrote:

-David


On Nov 17, 2009, at 2:33 PM, Scott Gray 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.

Hi Bilgin,




The form definition would look like this:
<field name="country>

<field-event>
  <set field="geoName" value="${parameters.country}%"/>
  <entity-condition entity-name="Geo" list="countries">
    <condition-list>

      <condition-expr field-name="geoTypeId" value="COUNTRY"/>
    </condition-list>
    <order-by field-name="geoName"/>
  </entity-condition>
</field-event>
</autcompleter>
</field>



Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 18/11/2009, at 3:17 AM, Bilgin Ibryam wrote:

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. <autocompleter result-field="countries" result-value-name="geoId" result-description-name="geoName"> <condition-expr field-name="geoName" operator="like" from- field="geoName" ignore-case="true"/> 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.

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

I'd be glad to hear your opinion on this.

Regards,
Bilgin Ibryam

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.

smime.p7s
Description: S/MIME cryptographic signature