ComboBox and SuggestionBox migration to 4.0

[ilya_shaikovsky]

There I want to rise some question and points to be discussed for the combo and suggestion box components.

1) The first questions I wanted to rise - if we really need two components?

Actually combobox was designed after request to provide more lightweight component without table in popup and using client side suggestions.

I believe we could combine that in one component. E.g.

= for markup we could add attribute which could switch the component presentation or just make decision according to the fact if the user defined custom markup using columns inside or not.

= for data fetching way we could also add both definitions possibilities to the same component and just restrict usage of both in the same time. So the component could be defined either with suggestionValues for client side suggestion or with autocomplete method which should be called to fetch the data.

The second point of view.

If we will leave suggestion as is as separate component we could add possibility to attach it to multiple input components. In this case performance improvement will be achieved for example when the component should be used in tables or just for many fields of the user form.

2) Proposals list

This list not includes full features listing. There are just RFCs risen for current components functionality.
http://tinyurl.com/ykjyqhx

2.1) data fetching.

= Allow to pre-render the suggestions. It should be possible for ajax fetching mode.

= Allow to minimize count of request in ajax fetching mode. E.g. if the user not removing new characters but continue typing he could want the component just to filter already fetched list and not request the data for new prefix again and again. And if the characters removed (already entered prefix changed) - only then new list should be requested.

= Minimize count of request in ajax fetching mode by using caching. If the component already fetched some list for prefix then popup closed and the list called again without prefix change - request should not be called second time.

= DataScroller support. Provide the pagination mechanisms for long suggestion lists.

2.2)component markup

= additional facets header, footer for popup. And the same ones for columns should be supported if columns used in markup.

= inline markup for the component should be supported

2.3) input changes and suggestion filtering

= Provide mode where component js will not allow to enter the value which isn't suggested. (aka select mode)

= enableManualInput could be implemented in order not to allow keyboard input at all. So the component functionally become a select.

2.4) Misc

= google like suggestions. Nothing selected by default when suggestion appears so pressing enter not causes anything to be selected.

= If suggestion will be decided to implement as separate component. It should provide built-in input instead of to be attached to
some external one. Discussed many times at user forums and will allow us to rise the events more carefully (changing, component focusing and blur..)
== Also suggestions calling button should be optionally available for this case.

= more careful keyboard support. (just need to revise a few RFC issues in jira)

= careful JS API implementation. User should be able to
== fill the list on the client according to his logic.
== change the list by adding/removing some items from suggestions
== call suggestion popup with or without(cached) Ajax request from external js


To be continued...

[jbalunas]

"ilya_shaikovsky" wrote:
There I want to rise some question and points to be discussed for the combo and suggestion box components.

1) The first questions I wanted to rise - if we really need two components?

Actually combobox was designed after request to provide more lightweight component without table in popup and using client side suggestions.

I would like to see these combined if it can be done with the performance improvements that you mention below. As you say this component was requested because it is more light weight.

= for markup we could add attribute which could switch the component presentation or just make decision according to the fact if the user defined custom markup using columns inside or not.

/me brainstorming - Would it be possible to create a facet that defines the contents of the popup if the default [simple] approach is not wanted? In this facet the user could define a table or what ever they want. This way there is not a table by default.

The second point of view.

If we will leave suggestion as is as separate component we could add possibility to attach it to multiple input components. In this case performance improvement will be achieved for example when the component should be used in tables or just for many fields of the user form.

Why would this require leaving them as separate components?

2) Proposals list

This list not includes full features listing. There are just RFCs risen for current components functionality.
http://tinyurl.com/ykjyqhx

List sorted by votes - http://tinyurl.com/ygrj5sk

= Allow to minimize count of request in ajax fetching mode. E.g. if the user not removing new characters but continue typing he could want the component just to filter already fetched list and not request the data for new prefix again and again. And if the characters removed (already entered prefix changed) - only then new list should be requested.

= Minimize count of request in ajax fetching mode by using caching. If the component already fetched some list for prefix then popup closed and the list called again without prefix change - request should not be called second time.

The two ideas above seem related so I'll share the comment. I think optimizations like this would be good. It seems to me both would need to have the ability to toggle on/off.

Also correct me if I'm wrong, but the first suggestion can be done without caching - it is simply using the list it already has. But I agree that to handle this when removing/replace characters you need caching.

= DataScroller support. Provide the pagination mechanisms for long suggestion lists.

= additional facets header, footer for popup. And the same ones for columns should be supported if columns used in markup.

I think this would be up to the user if we allow them to define the pop-up.

= Provide mode where component js will not allow to enter the value which isn't suggested. (aka select mode)

= enableManualInput could be implemented in order not to allow keyboard input at all. So the component functionally become a select.

+1 - if not adding too much complexity.

= If suggestion will be decided to implement as separate component. It should provide built-in input instead of to be attached to
some external one. Discussed many times at user forums and will allow us to rise the events more carefully (changing, component focusing and blur..)
== Also suggestions calling button should be optionally available for this case.

This would be opposite of the idea above that you can attach suggestion box to multiple inputs. Could these co-exist?

= more careful keyboard support. (just need to revise a few RFC issues in jira)

= careful JS API implementation. User should be able to
== fill the list on the client according to his logic.
== change the list by adding/removing some items from suggestions
== call suggestion popup with or without(cached) Ajax request from external js

+1 again if this does not add too much complexity.

[ilya_shaikovsky]

/me brainstorming - Would it be possible to create a facet that defines the contents of the popup if the default [simple] approach is not wanted? In this facet the user could define a table or what ever they want. This way there is not a table by default.

also thought about something like TreeNode for tree. Just facet where markup defined and data representation defined inside using some var variable.

Why would this require leaving them as separate components?

The users often asks to provide possiblity just to say for="input1, input2, input3..." and have the same instance attached to all the inputs because of performance improvement. But from the other side - having input built in to component itself and having js object instance for every input - allows us to handle events more carefully and resolve problems when the external input component re-Rendered and SB component lost its DOM instance.(https://jira.jboss.org/jira/browse/RF-7527). But in general you're right and we could try to go with both definitions. Just define at component if it should be attached or should generate it's own input.

This would be opposite of the idea above that you can attach suggestion box to multiple inputs. Could these co-exist?

So, again I'm just talking about that both approaches has its own advantages and the users asked about both ones for different cases. As for me I personally think that calendar component in 3.3.x implemented in best manner which could be utilized in order to go with just bundled input component(if we will decide one approach isntead of implementing both). There all the initialization removed from rendering time and performed only when component actually called. That allowed us to resolve performance problems mostly.

[jbalunas]

So to me it seems the next step is to get some estimates of effort for some of these options, and make a choice based on those.

In general I would lead towards combining the components with an option to either include an embedded input component, or allow the suggestion box to be attached to X input components.

[admitriev]

You can see Combo- and Suggestion Boxes layout here: https://jira.jboss.org/jira/secure/attachment/12330075/boxes.zip. This is inline markup.

[nbelaevski]

"ilya_shaikovsky" wrote:
There I want to rise some question and points to be discussed for the combo and suggestion box components.

1) The first questions I wanted to rise - if we really need two components?

Actually combobox was designed after request to provide more lightweight component without table in popup and using client side suggestions.

I would like to see these combined if it can be done with the performance improvements that you mention below. As you say this component was requested because it is more light weight.

I'm still in doubts about that: we'll need two different behaviors - one as UISelect(Many?), another as UIInput; but both encapsulated in the same component. Seems a bit confusing.

= for markup we could add attribute which could switch the component presentation or just make decision according to the fact if the user defined custom markup using columns inside or not.

/me brainstorming - Would it be possible to create a facet that defines the contents of the popup if the default [simple] approach is not wanted? In this facet the user could define a table or what ever they want. This way there is not a table by default.

+1 - instead of implementing iteration-based functionality for suggestionBox, I'd like to see separation of concerns, where suggestionBox and repeat employ their built-in behaviors to do job for the user.

The second point of view.

If we will leave suggestion as is as separate component we could add possibility to attach it to multiple input components. In this case performance improvement will be achieved for example when the component should be used in tables or just for many fields of the user form.

Why would this require leaving them as separate components?

I guess that's because only one single instance of suggestion box is shown to the user, while combo boxes are visible all the time.

= Provide mode where component js will not allow to enter the value which isn't suggested. (aka select mode)

= enableManualInput could be implemented in order not to allow keyboard input at all. So the component functionally become a select.

+1 - if not adding too much complexity.

Requests for select feature have been raised all the time, for both combo box and suggestion box.

= If suggestion will be decided to implement as separate component. It should provide built-in input instead of to be attached to
some external one. Discussed many times at user forums and will allow us to rise the events more carefully (changing, component focusing and blur..)
== Also suggestions calling button should be optionally available for this case.

This would be opposite of the idea above that you can attach suggestion box to multiple inputs. Could these co-exist?

I think yes.

= more careful keyboard support. (just need to revise a few RFC issues in jira)

= careful JS API implementation. User should be able to
== fill the list on the client according to his logic.
== change the list by adding/removing some items from suggestions
== call suggestion popup with or without(cached) Ajax request from external js

+1 again if this does not add too much complexity.

+1 from me also.

[jbalunas]

"nbelaevski" wrote:

I'm still in doubts about that: we'll need two different behaviors - one as UISelect(Many?), another as UIInput; but both encapsulated in the same component. Seems a bit confusing.

That is a good argument against combining. If we do not combine then combobox could contain a "built in" input, while suggestion box would not, and could be attached to multiple inputs as discussed.

All the other comments we both agree on. Any other thoughts?