I want to show a h:selectManyMenu with some selected Values. The user should be able to scroll and see the values, but should not be able to change anything. But if I set disabled to true, then the menu is disabled and is not scrollable. Are there any ways of doing it? I am using primefaces 3.5
As the name of the component says it's a "select" many menu, which is intended to be used to select values. It would be illogical to disable this functionality.
You should try to take a look at different components like the DataList:
http://www.primefaces.org/showcase/ui/dataListHome.jsf
Perhaps combined with a ScrollPanel:
http://www.primefaces.org/showcase/ui/scrollPanel.jsf
Related
I need to implement a drop-down which has a delete 'X' option next to each option item. Somewhat like the image shown below.
The drop-down is populated dynamically and I need a way that does not inlvolve using list as an alternative.
EDIT: The icons next to each dropdown item refers to 'Edit'/'Delete'
You cannot put a checkbox into the usual <select> or multi-select HTML element.
However, here is another question where several good options are discussed.
This looks like the most useful and best suited to your purpose:
https://stackoverflow.com/a/27547021/1447509
And here is an example of how to change the default checkmark to an X:
https://stackoverflow.com/a/40123793/1447509
Sources:
How to use Checkbox inside Select Option
After selecting check box Instead of Tick symbol need X in html
UPDATE:
Given that you need both the HTML markup and the javascript to make it do what you want, you have two (possibly 3) steps to do:
This answer provides a good example of how to create the custom-rolled <select> control.
This answer shows you how to replace the checkbox created in step 1 with an icon/image of your choosing.
The javascript to remove the x'd <option> is very simple:
$(this).closest('option').remove();
IF you also need to save these results, then you also need to learn:
4a. Server-side SESSIONS (so that each user's customizations are saved for them)
4b. A login system, so you know for which user to save the current customizations.
4c. Just the basics of how to use a back-end database, such as MySQL/MariaDB, in which to store the user customizations.
4d. AJAX - so you can schlep info to the back-end for insertion into the database without refreshing (or navigating away from) the current page. AJAX replaces the ancient and no-longer-used <form> construct. Frankly, once you've used AJAX a couple of times, you'll never go back. Totally easy.
If you are in a bind and need someone to create the whole thing for you, I refer you to one of these websites - I have used such services myself and can recommend them.
Currently I develop a system will auto select options from list depend of user input. The issue I facing is once the selected='selected' attribute removed and use js re-add again the layout will not showing highlight even the html element is showing selected='selected'.I has been try submit the record, endpoint not getting any data from it, Any way to solve this issue ?
We are porting our MFC based client to Dojo. Is there any widget similar to listbox control. At present I am using DataGrid, but that seems heavy and overkill for our purposes. Alternatively what is best widget to replace listbox.
Update: I have already looked at dijit.form.multiselect, and I dont think that meets my requirement. MFC Listbox typically looks like this. I dont see (or rather dont know) how to replicate this with multiselect. It is possible that DataGrid is best fit for the control.
If you use dojo 1.7, take a look at the new DGrid.
For an example looking like yours, go to the tests page and pickup the Selector.html example.
Here are some options depending on which part of the ListBox you want to create:
dijit.Dialog to create a basic dialog box.
dijit.form.FilteringSelect to create a drop-down with your options (single select only).
You could also use radio buttons or checkboxes for your options depending on whether multiple selections are allowed.
I'm having an argument with a co-worker, and I'm trying to convince him that it's a bad idea to change checkbox text (label) according to the checkbox state.
For example, we have a combobox that automatically picks selected value (and is disabled) when checkbox next to it is checked and is enabled when checkbox is cleared. His idea is to show Autoselect when checkbox is checked and Manual select when it's cleared. I'm sure that this will confuse the user as users tend to think that checking a checkbox next to a verb will make it true, only to find that the label has changed to something else.
What is your opinion on this matter?
P.S. I remember reading about changing checkbox text somewhere, in a book or blog article, but can't remember where. It would be great to have this in writing :-)
No need to mess with something that already works.
Changing the label would be horribly confusing and counter-intuitive, especially in the way you describe.
If the label describes the current state ("Manual select"), it will not be clear whether it is necessary to click on the checkbox to achieve the described state (like with a button), or whether it already is in that state.
A checkbox is a simple thing. When it is off, it does A. When it's on, it doesn't do A. The label needs to reflect what it does when it's turned on; it is then perfectly clear what doesn't happen when it is turned off.
If you want to show that the choice is between "Auto select" and "Manual select" then you should either reword your checkbox label or have a radio button:
o Manual Select
* Auto Select
Which isn't really ideal either.
But you shouldn't be changing the text on the label - the user won't remember what it was before and will be confused when it changes.
Personnaly i would say that the label shouldn't change.
From my experience changing the text is confusing, I have the same issue with modal buttons that change their text. It is hard to tell whether pushing the button will turn on the selected state or the text is the selected state.
Tick box text should not change.
Changing the text when the checkbox is checked changes the meaning. If it's checked and the label says Autoselect, I expect the Autoselect option to be enabled. If you uncheck, it's clear that the Autoselect option is NOT enabled. If you change the text to be Manual select whenever the checkbox is cleared I would expect that checking the box would enable the Manual select option. It's way too confusing if the text keeps changing.
You're right, he's wrong.
Checkbox labels should not change. That's part of the way checkboxes work.
See Should “toggle buttons” show what they do or the system status? on UXExchange for an alterantive approach using toggle buttons instead of checkboxes.
The label definitely shouldn't change. It's not only confusing, but it's unnecessary and ugly.
The only way I can think to make it less confusing would be to have the label state in brackets the current state, i.e. "Manual(currently auto)[]".
But that's really just a testiment to how ugly it gets.
Don't mess with what people are used to. Especially when you consider that if you do this, one will always be shown WITH a checkmark, and the other WITHOUT. Really confusing.
In the name of compromise, you COULD use a button instead, which toggles the control back and forth, and changes its value with each click.
Current mode: [Manual]
Still kind of confusing though. As I said, don't mess with what people are used to. It's like if you put a scrollbar on the left of the screen. It'll just mess with peoples' heads.
I would not change the checkbox label... I would have it say "automatic." But, depending on what your controls are actually doing, I might modify the selection in the grayed-out combo-box to reflect that it is now under automatic control.
Then to make the logic go both ways, if while the checkbox was unchecked, the user selected the "automatic" value in the combo-box, the checkbox would then become checked.
Or in another scenario:
If, when the "automatic" checkbox is checked, the automatic logic actually chooses a default value that is in the combo-box, then change the selection in the combo-box to show what the automatic setting actually is. The combo would not be editable, but it could be used to provide information about the actual setting that is being engaged.
In my specific example, I'm dealing with a drop-down, e.g.:
<select name="foo" id="bar">
<option disabled="disabled" selected="selected">Select an item:</option>
<option>an item</option>
<option>another item</option>
</select>
Of course, that's pretty nonsensical, but I'm wondering whether any strict behaviour is defined. Opera effectively rejects the 'selected' attribute and selects the next item in the list. All other browsers appear to allow it, and it remains selected.
Update: To clarify, I'm specifically interested in the initial selection. I'm dealing with one of those 'Select an item:'-type drop-downs, in which case the first option is really a label, and an action occurs onchange(). This is fairly well 'progressively enhanced', in that a submit button is present, and only removed via JavaScript. If the "select..." option were removed, whatever then were to become the first item would not be selectable. Are we just ruling out onchange drop downs altogether, or should the "select..." option be selectable, just with no effect?
The HTML specs are a bit vague (ie. completely lacking) with regard to this odd combination. They do say that a form element with the disabled attribute set should not be successful, so it really can't be selected.
The browser may well render it so that it looks selected, but it shouldn't show up in the POSTed data. Looks like Opera's got it right to me.
The HTML specs state that both selected & disabled are available options for the <option> element, but doesn't specify what should happen in case of a conflict. In the section on disabled controls it says
When set, the disabled attribute has
the following effects on an element:
Disabled controls do not receive focus.
Disabled controls are skipped in tabbing navigation.
Disabled controls cannot be successful.
it also says
How disabled elements are rendered depends on the user agent. For example, some user agents "gray out" disabled menu items, button labels, etc. In this example, the INPUT element is disabled. Therefore, it cannot receive user input nor will its value be submitted with the form.
While this specific case isn't specified, my reading of this says that the actual rendering of a 'selected' 'disabled' element is left up to the browser. As long as the user cannot select it then it's working as standard. It does say that a script can act upon the element, so it is possible for Javascript to set a disabled option as selected (or disable a selected option). This isn't contrary to the standards, but on form submission, that option's value couldn't be the selected value. The select list would (I assume) have to have an empty value in this case.
In reply to the update in the question, I would say that the 'label' option should be selectable but either make it do nothing on submission or via JavaScript, don't allow the form to be submitted without a value being selected (assuming it's a required field).
From a usablilty point of view I'd suggest doing both, that way all bases are covered.
According to the HTML 4.01 Specification, disabled is a standard attribute for the option element, but behavior is probably indeterminate based on the standard (read over the information on the select element and the options elements. Here is a portion I think may shed light on Opera's reasons for their implementation:
When set, the disabled attribute has the following effects on an element:
* Disabled controls do not receive focus.
* Disabled controls are skipped in tabbing navigation.
* Disabled controls cannot be successful.
So, it is very likely that this is just one of those things where the spec is vague enough to allow for both interpretations. This is the kind of idiosyncrasy that makes programming for the web so fun and rewarding. :P
Are we just ruling out 'onchange' drop
downs altogether, or should the
"select..." option be selectable, just
with no effect?
"onchange" drop-downs are frowned upon by more standards-obsessed types.
I would typically do some client-side validation. "Please select an item from the drop down" kind of thing. i.e.
should the "select..." option be selectable, just with no effect?
So I just said "Yes" to your A or B question. :/ Sorry!
unfortunately it doesn't really matter what should happen, because IE doesn't support the disabled attribute on options period.
http://webbugtrack.blogspot.com/2007/11/bug-293-cant-disable-options-in-ie.html