incubation is all about building a community of committed users/developers. not a big deal to do a checkout on the current 1.0.1-SNAP for now.
As Adam said, most important is to have a release; the dependencies for CORE are already released, so ... we can do another release soon... -M On 3/9/07, Adam Winer <[EMAIL PROTECTED]> wrote:
The 1.0.0 branch basically already happened... But I'll have a look at it now. No reason we can't do a 1.0.1 release soon. (IMO, the most important thing about a 1.0.0 release is just having the darn thing!) -- Adam On 3/8/07, Steve Vangasse <[EMAIL PROTECTED]> wrote: > Thanks Adam. > > Any luck looking at the code? Should I enter the bug with jira? It would > be great to have this fixed before the upcoming release. > > Cheers, > > Steve Vangasse > > > > -----Original Message----- > From: Adam Winer [mailto:[EMAIL PROTECTED] > Sent: 07 March 2007 17:14 > To: [email protected] > Subject: Re: selectManyListbox issue > > I'd need to look at the code, but if I remember correctly, the > selectedIndices array is supposed to be sorted before here. > I've got a bad feeling that the sorting was removed in at least one code > path at some point in the recent past, while fixing some shuttle bugs. > > -- Adam > > On 3/5/07, Steve Vangasse <[EMAIL PROTECTED]> wrote: > > I've looked a little further into this and it looks like it might be a > > > bug in Trinidad. In SimpleSelectManyRenderer getSelectedIndices() > > method an int array called indices is used to define the index of each > > > value in the selection list. The code works fine when the selection > > list and the value list are in the same order, but when they are > > different it breaks down. > > > > The indices array is passed to SimpleSelectManyListboxRenderer > > encodeElementContent() method where assignment of the boolean selected > > > variable relies on the values in the array being in numerical order: > > > > > > > > int selectedCount = selectedIndices.length; > > int selectedEntry = 0; > > for (int i = 0; i < count; i++) > > { > > boolean selected = ((selectedEntry < selectedCount) && > > (i == selectedIndices[selectedEntry])); > > if (selected) > > selectedEntry++; > > > > SelectItem item = selectItems.get(i); > > SimpleSelectOneRenderer.encodeOption( > > context, arc, component, item, converter, > > valuePassThru, i, selected); > > } > > > > > > > > When the selection list and the value list have different ordering the > > > values in the indices array are not in numerical order. The code then > > misses selected elements and they are not rendered as selected. Is > > this a bug? > > > > Thanks, > > > > Steve Vangasse > > > > > > > > -----Original Message----- > > From: Steve Vangasse [mailto:[EMAIL PROTECTED] > > Sent: 16 February 2007 17:19 > > To: [email protected] > > Subject: tr:selectManyListbox issue > > > > Is anyone else having issues with tr:selectManyListbox on the current > > trinidad snapshot. It only renders one option as selected on a list > > where there a multiple selections. Submitting the form with multiple > > selections updates the model correctly but then renders just the one > > as selected. > > > > <tr:selectManyListbox label="#{msgs.deliveryZones}" > > value="#{salesOrders$delivery$optionForm.crudObject.zones}" > > required="true"> > > <f:selectItems > > value="#{salesOrders$delivery$deliveryUtils.zones}"/> > > </tr:selectManyListbox> > > > > salesOrders$delivery$optionForm.crudObject.zones is a List of objects > > and salesOrders$delivery$deliveryUtils.zones is a List of SelectItems > > whose vales are the complete set of those objects. > > > > Any ideas? > > > > Thanks, > > > > Steve Vangasse > > > > > >
-- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
