14 Replies Latest reply on Jan 28, 2012 2:39 AM by bleathem

rich:select enhancements and rethink

justinwyer Jun 19, 2011 12:02 PM

There are 3 things to discuss (maybe we will come up with more)

Firstly continuing from the 15/6 team meeting rich:select with enableManualInput=true has some use case problems if we follow these screen shots

User clicks the rich:select to open item list

User uses manual input to scope the item list

This is worked correctly so far and our user goes ahead and selects "112 Orange" but then they change their mind so they display the item list again by clicking on the input / drop down button and this is what they see

The item list only has one item in it now because enableManualInput has scoped the list to match the value of the input. More savvy users will realise they can hit backspace a lot or ctrl + a and start typing again but many users will end up confused. Regardless of the user this is awkward.

I purpose the entire item list be displayed and text in the input auto highlighted so if the user starts typing the input text will be cleared and the list will get scoped as per the second screenshot.

Secondly the onclick attribute is broken as it only affects the input not the drop down button. We could introduce two new events oninputclick onbuttonclick and onclick could wrap both of these. Discussing this lead to Lukas suggesting that we rather introduce semantical events onlistopen and onlistclose which I agree with.

Thirdly the setValue(value) js api call does not allow for the input text to be cleared, we can either extend the method to clear the list if '' or null are passed as the value or we can introduce a new call clear() or clearInput()

1. Re: rich:select enhancements and rethink

lfryc Jun 23, 2011 11:16 AM (in response to justinwyer)

Hi Justin,

as I said previously, this is reasonable and I feel this behavior wrong the same as you.

However I would also like to hear other opinions on how this should behave (and possibly why we have decided to go current way).
Actions
2. Re: rich:select enhancements and rethink

jbalunas Jun 23, 2011 11:44 AM (in response to lfryc)

Sorry guys, just got back from JSFSummit, and traveled until late last night. I'll comment on this asap!!
Actions
3. Re: rich:select enhancements and rethink

jbalunas Jun 24, 2011 9:08 AM (in response to justinwyer)

The item list only has one item in it now because enableManualInput has scoped the list to match the value of the input. More savvy users will realise they can hit backspace a lot or ctrl + a and start typing again but many users will end up confused. Regardless of the user this is awkward.

I purpose the entire item list be displayed and text in the input auto highlighted so if the user starts typing the input text will be cleared and the list will get scoped as per the second screenshot.
The pictures here certainly help to understand :-)

I would like you all to consider a different solution. Note - I'm not saying the solution suggested is bad, but just playing devils advocate ;-)

Instead of scoping the list, why don't we scroll to the first match. Take this for example, although it does not have manual input - it could.
Then you type "b" and get :

The select scrolls to the first match. This is nice because you avoid the scoping issue, however one problem with this approach is that it works best only if the items are sorted.

As I said I like the other approach as well. Lets discuss, and we'll get some jira created to cover the agreed way.
Actions
4. Re: rich:select enhancements and rethink

jbalunas Jun 24, 2011 9:11 AM (in response to justinwyer)

Secondly the onclick attribute is broken as it only affects the input not the drop down button. We could introduce two new events oninputclick onbuttonclick and onclick could wrap both of these. Discussing this lead to Lukas suggesting that we rather introduce semantical events onlistopen and onlistclose which I agree with.
If you have not already please created some feature request or enhancement jiras to cover these. These make sense, it will just be a matter of finding the time to implement.

If this is something you are interested in you are welcome to take a crack at it.

Thirdly the setValue(value) js api call does not allow for the input text to be cleared, we can either extend the method to clear the list if '' or null are passed as the value or we can introduce a new call clear() or clearInput()
What happens if you send in "" today? This seems a bug to me, please create a jira!

Great comments and feedback - keep it coming!!
Actions
5. Re: rich:select enhancements and rethink

justinwyer Jun 24, 2011 12:42 PM (in response to jbalunas)

Jay Balunas wrote:

Secondly the onclick attribute is broken as it only affects the input not the drop down button. We could introduce two new events oninputclick onbuttonclick and onclick could wrap both of these. Discussing this lead to Lukas suggesting that we rather introduce semantical events onlistopen and onlistclose which I agree with.
If you have not already please created some feature request or enhancement jiras to cover these. These make sense, it will just be a matter of finding the time to implement.

If this is something you are interested in you are welcome to take a crack at it.
I'll create the enhancement JIRA's and would like to take a stab at it.

Jay Balunas wrote:
Thirdly the setValue(value) js api call does not allow for the input text to be cleared, we can either extend the method to clear the list if '' or null are passed as the value or we can introduce a new call clear() or clearInput()
What happens if you send in "" today? This seems a bug to me, please create a jira!

Nothing happens if you setValue('') today as it searches the itemList for an item matching the value passed.
Actions
6. Re: rich:select enhancements and rethink

justinwyer Jun 24, 2011 12:49 PM (in response to jbalunas)

Jay Balunas wrote:

Instead of scoping the list, why don't we scroll to the first match. Take this for example, although it does not have manual input - it could.
Then you type "b" and get :

The select scrolls to the first match. This is nice because you avoid the scoping issue, however one problem with this approach is that it works best only if the items are sorted.

A +1 for the scoped list is it makes it easier for the user to manage the list with scoping and scrolling.
Actions
7. Re: rich:select enhancements and rethink

lfryc Jun 27, 2011 4:00 AM (in response to justinwyer)
For completeness, there is the issue

RF-10887
rich:select setValue(value) javascript api does not allow setting an empty value.
Actions
8. Re: rich:select enhancements and rethink

jbalunas Jun 27, 2011 10:28 AM (in response to justinwyer)

Can't wait to see what you come up with this and please let us know if you have questions or want to add a topic to the team meetings.

PS This is one of the great things about git - not having to manage SVN, and forking and updates area so much easier :-)
Actions
9. Re: rich:select enhancements and rethink

ilya_shaikovsky Jun 27, 2011 11:11 AM (in response to justinwyer)

B.t.w. I also added https://issues.jboss.org/browse/RF-9580 in the past. According to http://community.jboss.org/message/591176#591176 report.
Actions
10. Re: rich:select enhancements and rethink

justinwyer Jan 26, 2012 6:06 AM (in response to justinwyer)

The current state of the rich:select changes discussed in this post are as follows.

setValue('') or setValue(null) now clears the input as expected pull requested https://issues.jboss.org/browse/RF-10887
onlistshow and onlisthide events have been implemented pull requested https://issues.jboss.org/browse/RF-11087

The problem child is the enableManualInput the changes work fine in firefox but calling input.select() in chrome seems to be doing weird things and the input also appears to lose focus. So I may need some help or perhaps we need to rethink this, the changes for this are available in my fork of components in the RF-11088 branch https://github.com/justinwyer/rf-components/tree/RF-11088
Actions
11. Re: rich:select enhancements and rethink

jbalunas Jul 5, 2011 8:26 PM (in response to justinwyer)

Lets discuss in the team meeting tomorrow - I've added this to the agenda! With holidays and vacation we'll refocus on this tomorrow.
Actions
12. Re: rich:select enhancements and rethink

logan.mauzaize.infotel.com Jan 26, 2012 4:57 AM (in response to justinwyer)

Hi,

I'm expecting this behaviour for my current development (migrating from an home-made framework to the "standard" JSF/Richfaces 4.1). Our previous framework provides a similar features and we become really attached to this feature.

As our application is only targeting Mozilla Firefox 3.6 and Microsoft Internet Explorer 7-9, my team and I think we can patch our RichFaces JARs with the current development of this issue.
However the link on GitHub (https://github.com/justinwyer/components/tree/RF-11088) is broken and result in a page not found error (404). Anybody have a correct link or archive to provide ?

Thanks you !
Actions
13. Re: rich:select enhancements and rethink

justinwyer Jan 26, 2012 6:12 AM (in response to justinwyer)

An update to RF-11088 this upstream commit breaks the changes in my branch https://github.com/richfaces/components/commit/e28ee48a22b0aced146cb547f50f32d357f6912b I need to port my changes through.
Actions
14. Re: rich:select enhancements and rethink

bleathem Jan 28, 2012 2:39 AM (in response to justinwyer)

Hi Justin,

If you have any questions about the list refactoring I did, be sure to give me a shout - I'm almost always in IRC

Brian
Actions

Go to original post