I am implementing comboboxes in an application where IceFaces forms are being built dynamically. There are no xhtmls around, we put together everything from Java code. This works nice so far, but I am stucked at HtmlSelectOneListbox. In my code I create one that appears on the form as well correctly, but I don't know how to add the SelectItems to it.
HtmlSelectOneListbox combo = new HtmlSelectOneListbox();
combo.setId(id);
combo.setDisabled(readOnlyWindow);
/* parent is the UIComponent instance around us*/
parent.getChildren().add(combo);
I can create instances of SelectItems or even SelectItemsTag but the combo has no methods to set them. It has only a setValue/setValueExpression and with that I could set my value binding expression to the object representing #{bean.value}. But the selectitems property should be set not on the listbox but its nested f:selectItems that I don't know how to create.
I think UISelectItem and/or UISelectItems objects should be added as children of HtmlSelectOneListbox in a similar way you add combo to the parent component.
Related
I have a list of items that are pulled from a database, it combines the various fields with a rs.getString method to create a longer string of items, this is done in an action button method.
I would like to be able to click on an item in this list and have one of the fields display as text in a textbox, so this needs to be done through the list selection event method where I instruct the program to set the text to my desired value.
My problem is, I am not sure of the logic to follow in order to specify how to retrieve that fields information that will be corresponding to the item that is selected in the list, can you give me any ideas?
Rather the combining the fields into a single String, create a POJO (Plain Old Java Object), which provides getters (and possible setters) for the fields you want and these objects to the ListModel
Use a ListCellRenderer to customise the way which the JList renders the POJO the way you want to. See Writing a Custom Cell Renderer for more details.
When the user selects an item from the list, use JList#getSelectedValue and cast to the same class as your POJO. You can now use the POJO's getters to extract the properties you want to display.
The idea is to generate a self contained unit of work, which, based on what you want to do, you can customise how the object is displayed.
This concept is a corner stone to the separation of data (model) and the UI (view) behind the Model-View-Controller paradigm and OOP generally...
Note: anywhere I refer to a List in this question, I am talking about com.codename1.ui.List.
Can I use Codename One's GUI Designer to put a List in a List and then populate each sub-list with its own data?
I can define a Container in the GUI Designer and put a List in it (I'll call it InnerList) then set the Container as the Renderer for another List (I'll call this one OuterList.) What I have been unable to do is to then set the data for the InnerList in a particular cell of OuterList. When I modify OuterList's ListItems in the GUI, InnerList doesn't even appear in the list of keys, and I have not found a way to populate InnerList from code either.
To work around this problem, I have had to define two user classes implementing ListCellRenderer (and extending Container) and, in code, set them as the renderers for OuterList and InnerList, respectively. In the GUI Designer, there is only OuterList with no apparent Renderer. This works, but it doesn't really fit in with the way the rest of the GUI is defined and it adds confusion.
No.
This wouldn't make any sense. Codename One list renderer's are "rubber stamps" which means they have no state and so you will not be able to vary the size of the elements or access individual components within them. What you need to do is use a Component->Container hierarchy to achieve the functionality you are seeking.
I have a TableViewer where the values in one column should typically come from a dynamic list.
I'm currently using org.eclipse.jface.viewers.ComboBoxCellEditor , which is actually a Select-List: it stores the index of the selected value. If I change the underlying list (calling setItems(String[]), it's clumsy to keep the previous selected value... (specially if it's not included in the list anymore!) What I'd wish is actually a cell editor that stores, not the index from the list, but the string (perhaps letting the user edit it freely, perhaps not), where the list is just used as a suggestion at input time - like a "combobox" was supposed to work in the good old days... Is this possible?
I would suggest you to have your CellEditor to mimic the behavior that you are looking for. Extend ComboBoxViewerCellEditor and override doGetValue() method. Add modify listener on Combo control and also filter (which filters list items based on input text) to comboviewer.
You should look at :
org.eclipse.wst.xml.ui.internal.properties.StringComboBoxCellEditor This class comes from WTP project; It's an extended ComboBoxCellEditor that selects and returns Strings.
codemirror.eclipse.ui.xquery.viewers.StringComboBoxCellEditor It's the copy/paste of WTP StringComboBoxCellEditor; it adds the capability to add the item in the combo when it is not found.
I have a JSF form that consists of a grid and some detail fields. The detail fields contain the data of the first row in the grid. I have a backing bean that listens to the grid row selection and updates the detail fields' backing beans to represent the new values. Here comes the problem: I update the detail fields as needed (the listener is invoked in the ApplyRequestValuesPhase), but later the JSF framework reassings the old values to them in the UpdateModelValuesPhase.
My question is how to fix it? How could I assign new values to some JSF components from the grid selection change event?
Note: this is about the very the same thing as in JSF component doesn't update if changes came from grid click but I see the problem more clearly now I think, that's why I posted a new question.
It's not normal that a listener is invoked during apply request values phase. Perhaps you've set immediate="true" somewhere which will cause the actions to be performed during apply request values phase. You need to make sure that the listener is invoked during the invoke action phase which runs right after the update model values phase. Set immediate="false" or just remove the attribute altogether, it's the default behaviour already.
As per the comments, you seem to indeed have set the immediate="true" on the row selector, you'd need to remove it.
Here's the sit:
I have a JSF component which is basically a list of 'documents'
I have any number of document viewer components on the same page.
None of these components "know" about each other. In other words, they cannot be configured at design time to link to each other or anything like that.
When the user clicks a document link I wish each one of the document viewer components to be notified.
Basically the idea would be to have the document viewers publish the fact that they listen for a certain type of event ("DocumentSelectedEvent" say) which the doc list component would fire.
I can think of ways of doing this that are not JSF specific, but I'm wondering if the JSF event model can handle that sort of thing.
Anyone have any ideas?
I don't think there's a way of doing that with the standard JSF event model.
Is there any way you can bind the components to a backing bean? That way when an event happens you can just go through your list of components and notify each of them.
You need to just bind the components with a backing bean and use a ValueChangeListener to notify the backing bean. The listener method could change the state of the other components which are tied to respective UI components.
Are you trying to do it in a "Ajax" way without page being explicitly submitted?
ValueChangeEvent
I do not know how you implemented your document list but if it were say a dropdown or any other multi item list component you can do an Value Change Event and force a submit on change for the component. Then in the page code backing bean you can call the methods for your viewers to load whatever you like.
In your jsf you just specify the value change handler you wrote in the backing bean.
/**
* Handle document click value change.
*
* #param valueChangedEvent the value changed event
*/
public void handleDocumentSelect(ValueChangeEvent valueChangedEvent) {
String selectedDocument = valueChangedEvent.getNewValue();
doDocViewer1DisplayMethod(selectedDocument);
doDocViewe2DisplayMethod(selectedDocument);
}
Modify your jsf tag to use your new value change event handler and force the submit.
<f:componentTag
attr=xxx
attr=xxx
valueChangeListener="#{pc_BackingBean.handleDocumentSelect}"
onChange=submit();>