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
