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
