14 Replies Latest reply: Jan 28, 2012 2:39 AM by Brian Leathem RSS

rich:select enhancements and rethink

Justin Wyer Newbie

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

 

select1.png

User clicks the rich:select to open item list

 

select2.png

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

 

select3.png

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
    Lukáš Fryč Master

    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).

  • 2. Re: rich:select enhancements and rethink
    Jay Balunas Master

    Sorry guys, just got back from JSFSummit, and traveled until late last night.  I'll comment on this asap!!

  • 3. Re: rich:select enhancements and rethink
    Jay Balunas Master

    select3.png

    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.

    Untitled.png

    Then you type "b" and get :

    Untitled.png

     

    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.

  • 4. Re: rich:select enhancements and rethink
    Jay Balunas Master

    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!!

  • 5. Re: rich:select enhancements and rethink
    Justin Wyer Newbie

    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.

  • 6. Re: rich:select enhancements and rethink
    Justin Wyer Newbie

    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.

    Untitled.png

    Then you type "b" and get :

    Untitled.png

     

    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.

  • 8. Re: rich:select enhancements and rethink
    Jay Balunas Master

    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 :-)

  • 10. Re: rich:select enhancements and rethink
    Justin Wyer Newbie

    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

  • 11. Re: rich:select enhancements and rethink
    Jay Balunas Master

    Lets discuss in the team meeting tomorrow - I've added this to the agenda!  With holidays and vacation we'll refocus on this tomorrow.

  • 12. Re: rich:select enhancements and rethink
    Logan M Newbie

    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 !

  • 13. Re: rich:select enhancements and rethink
    Justin Wyer Newbie

    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.

  • 14. Re: rich:select enhancements and rethink
    Brian Leathem Master

    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