Yeah, the main risk here is trying too hard to generalize. Sometimes trying to make things fit into a common model ends up making the code more complex or difficult to follow. However, I'm all for generalizing when it applies.
On Sep 17, 2010, at 7:32 PM, Chris Bartlett wrote: > On 18 September 2010 06:24, Chris Bartlett <[email protected]> wrote: > >> >> >> On 18 September 2010 05:59, Greg Brown <[email protected]> wrote: >> >>>>>>> 3. (Improvement / New Feature) >>>>>>>> XXX.keyTyped() methods which select the next item matching the >>> keypress >>>>>>>> should probably >>>>>>>> - Move in the opposite direction when SHIFT is pressed >>>>>> >>>>>> Just as before, it is a continuation of the SHIFT key reversing >>> direction >>>>> >>>>> That's what I figured, but is this a common convention? I have never >>> heard >>>>> of it before. >>>>> >>>>> >>>> I couldn't tell you of a single place off the top of my head where this >>>> does occur, but it was something that seemed natural to my (clearly) >>>> perverted way of thinking ;) >>> >>> I can actually see the utility in it - but if it is not a widely known >>> convention, users may not even think to try it, so not worth the effort of >>> coding/testing. >>> >>> I'd rather see some effort go into the wrapping functionality, since this >>> is actually a common convention that we don't currently support. >>> >>> >>> >> >> I was thinking that it might be worth trying to consolidate the way this >> kind of thing is handled throughout Pivot as it happens in a number of >> places and the resulting code is not especially pretty. >> >> Something along the lines of >> >> public static int helperMethod(Sequence<T> items, int startIndex, Direction >> direction, Filter<T> filter) >> >> You would pass it the list of items, a starting point & direction of >> 'travel'. >> It would take care of the while loops to iterate over potentially the >> entire sequence, until it finds an object T which fulfills the required >> selection criteria (such as enabled and 'toString() starts with a letter >> A') >> >> Possibly also include another boolean parameter to control if it 'wraps' or >> ends when it hits the Sequence bounds. >> >> Chris >> > > Just thought this over a bit more and handling Sequences directly wouldn't > really help much here. Better if the method could handle common components > that require this type of processing and call the appropriate methods. > Stuff like ListView.isItemDisabled() etc.
