listShuttle missed opportunity.

[swestbom]

A missed opportunity. look at the Tomahawk sandbox selectManyPicklist for a much cleaner implementation (admittedly without bells and whistles).

It is nice to have the detailed display options bypassing the selectitem, but that should have been an option, not a necessity.

It is nice that you have the ability to expose the selected and not selected items on the backend along with having a universe of selectable items to populate them. As an option it might make sense as the only way to use it it sucks. The unselected items are nothing more than the select item list minus the selected values, it didn't need to be and shouldn't have been on the backing beans.

The shuttle should have been nothing more or less than a toggle implementation of a select many list.

This one is an over engineered POC.

[sergeysmirnov]

"swestbom" wrote:
The unselected items are nothing more than the select item list minus the selected values, it didn't need to be and shouldn't have been on the backing beans.

I disagree with this statement.

[cyberanto]

Hmmm - the example on your online demo site is beautifully simple. Could not find that bean that is obviously being used on the web site in the test-application directory in the distribution (3.1.3GA), though.

Would it be possible to include the rf-demo with the release (I believe this was done in earlier releases). This may also help people who didn't use previous releases to find the required libraries apart from the 3 richfaces jars.

Thanks

[sergeysmirnov]

What does it mean "to include"? It is in the SVN and available in the war format as well. See the "Most Important Links" below.

[ilya_shaikovsky]

"swestbom" wrote:

It is nice that you have the ability to expose the selected and not selected items on the backend along with having a universe of selectable items to populate them. As an option it might make sense as the only way to use it it sucks. The unselected items are nothing more than the select item list minus the selected values, it didn't need to be and shouldn't have been on the backing beans.

I'm able to explain our decision.. This component in future will supports "copy" mode. In this mode - you'll not able to use one "selection" attribute. Becase one selectItem will be just copied in this mode to resulting list. And if copied item should not be selected in target list while the source one should be - we should use two lists of selection.

This lists provided to make the component compatible in future. ;)

[swestbom]

"SergeySmirnov" wrote:

"swestbom" wrote:
The unselected items are nothing more than the select item list minus the selected values, it didn't need to be and shouldn't have been on the backing beans.

I disagree with this statement.

Try the Tomahawk tag, yours is a PITB, theirs works just like the selectManyListbox. Yours has more features but I cannot just replace a selectManyListbox with it, you threw out the contract and reinvented the wheel.

Also the Tomahawk tag makes the converter side of things very simple, the converter has everything it needs from the selectitem collection to handle the bean conversion, it is nicely self contained, the SelectItem key is used to find the bean the value contains the Pojo.

What were you trying to solve?

Can you elaborate on the intent? Am I just not getting it?

[baz]

Hello,
this component is very useful for me, congratulations.
First of all, it can display more than one column.
And the future "copy" mode is apreciated by us.

And further more, a listShuttle is more as a replacement for selectManyListbox.
Just our 2 cents.
BTW what does PITB mean, hopefully not the same as PITA?

[swestbom]

"baz" wrote:
Hello,
this component is very useful for me, congratulations.
First of all, it can display more than one column.
And the future "copy" mode is apreciated by us.

And further more, a listShuttle is more as a replacement for selectManyListbox.
Just our 2 cents.
BTW what does PITB mean, hopefully not the same as PITA?

The Tomahawk tag is a better replacement for selectManyListbox, it drops right in, no back end coding required. My complaint with this tag is it has no ability to be dropped right in, it requires a redesign of the backing bean, the converter and any back end logic to deal with the collections. If I have a use case that involves simply moving membership collections between entities the listShuttle will be useful, but for now it is a wasted opportunity for selectManyListbox applications.

[swestbom]

"baz" wrote:
Hello,
this component is very useful for me, congratulations.
First of all, it can display more than one column.
And the future "copy" mode is apreciated by us.

And further more, a listShuttle is more as a replacement for selectManyListbox.
Just our 2 cents.
BTW what does PITB mean, hopefully not the same as PITA?

PITB: Perfectly Implemented Technological Breakthrough? :)

[nbelaevski]

selectManyPicklist doesn't persist elements ordering. For us the ordering is important as you can see.

[trouby]

I partially agree with swestbom,

JSF's selectManyListbox is ugly but technically it's very easy to use,
selectManyPicklist is very simple to use, it looks good and is a very fast replacement for selectManyListbox, no code modifications required at all,


from the other side, listShuffle seems to be very advanced,
but too complicated for many simple scenarios, I have tons of multiple selection components, making code modification is silly, they are all just simple many2many hibernate relations...


It could be nice if it would easily fit as a replacement for 'selectManyListbox' but still have advanced capabilities such as element ordering, etc...


Asaf.

[demetrio812]

I also partially agree with swestbom because I'm glad there is such complete components but there are a lot of simple scenarios that would just need a selectManyListbox-like components (no matter of ordering or multi columns)...

so maybe it can work in different mode, like for ex. "simple" and "advanced"...

Demetrio