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.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.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".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
smime.p7s
Description: S/MIME cryptographic signature
