Messages posted by: edykory  XML
Profile for edykory -> Messages posted by edykory [319] Go to Page: Previous  1, 2, 3 , 4 ... 20, 21, 22 Next 
Author Message
Hi there,
I have this inputFile control
 <ice:inputFile id="inputFile" actionListener="#{uploadController.fileUploaded}" fileNamePattern=".+\.xml"
 	progressListener="#{fileUploadProgressListener.progressMade}" progressRender="true" />
 <ice:outputProgress value="#{fileUploadProgressListener.percent}" />

Nothing fancy ...
The problem is that all messages related to the inputFile get printed by the ice:messages control (invalid file, file too big, etc), except the one for the wrong file pattern
(The file name Xxxxxx does not match with the file name pattern xxxxx).
It does show in JBoss's log as

12:29:18,453 INFO [javax.enterprise.resource.webcontainer.jsf.lifecycle] WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
sourceId=inputFile[severity=(INFO 0), summary=(The file name Xxxxxx does not match with the file name pattern xxxxx), detail=(The file name Xxxxxx does not match with the file name pattern xxxxx)]

Any ideas?

After some investigation this has something to do with the fact that the first f:selectItem has a null itemValue. If I replace it with anything else, it works ok even with ice:selectOneMenu. But I wish it worked correctly from the very beginning, otherwise I lose "required" and "default" behavior.

Hi there
To make things short, these are the pieces of code
public class TestController {
 	private String textValue;
 	public String getTextValue() {
 		return textValue;
 	public void setTextValue(String textValue) {
 		this.textValue = textValue;
 	public String setNewValue() {
 		return null;

     <ice:selectOneMenu value="#{testController.textValue}">
         <f:selectItem  itemValue="" itemLabel="Choose value ..." />
         <f:selectItem  itemValue="1" itemLabel="Value 1" />
         <f:selectItem  itemValue="2" itemLabel="Value 2" />
     <ice:commandButton value="Set new value" action="#{testController.setNewValue}" />

Now, on the first pageload, if I push the button, nothing happens. If i select Value 1 and push the button, then Value 2 gets correctly selected.
The behavior does not happen with h:selectOneMenu instead of ice:selectOneMenu.

Eduard Korenschi
it's not really so ... the connectionTimeout parameter helps only if you have long serverside actions (that is, if generating the response upon a request takes more than 1 min or so) ...

Please check the IceFaces documentation (the 2 PDFs in the IceFaces distribution) and you'll see the meaning of all connection/hear beating related parameters.

A little bit off topic maybe, but if you try to access some session scoped data in a managed bean (works only with request or extended request scoped beans), then one elegant way to do is as follows:
1. In your managed bean declare the private field UserData userData with getter and setter
2. In faces-config.xml, where you declared your managed-bean, add a managed property:

Then you will have your field populated by the container (it will not work in bean's constructor though, but then you could overcome that with a @PostConstruct annotated methdo).

I don't think com.icesoft.faces.synchronousUpdate=false should generate Network Connection Interrupted, unless you open more than one page (the Asynchronous mechanism keeps a connection blocked all the time and there's a 2 connection / server limit in windows). I use it all the time (since we need server push) and never had any problems and I have a couple of projects deployed with tens of simultaneous users over quite low bandwidth (300-500kbs).

You need just to throw some tables on the screen? Nothing simpler. Take IceFaces (with Facelets of course) and Hibernate. Add to your entities a transient "selected" property for the rowSelector and you're done ... It really takes minutes to do everything. Of course, it's not just point-and-click ... but hey, for me it's the fun of programming and having most of the things under control.
If you want to just take a solution that works ... try Seam+IceFaces ... There's nothing more productive in the Java World ...

Strange? what do you mean by strange? Java developers can't be strange ... they're just a little bit unusual ... that's all.

PS: Get used to it :) IceFaces is extremely productive, but it has it's own "strange" aspects. You don't like them? Change them and then share the results, that's why we call it open source, remember?

If the table is not huge you could add partialSubmit="true" to your inputTexts (or to the form if you wish). But this will do a full form submit on each cell navigation (on inputText it's fired by onblur) so make sure your form doesn't have lots of fields, or the user's experience will suffer.

if you want to do it from the Java side, use
JavascriptContext.addJavascriptCall(FacesContext.getInstance(), "javascript_code")
where javascript_code should be something similar to Code:
window.open('http://www.yahoo.com', '_blank', 'some_other_options')

Check window.open method in a Javascript reference

And don't forget: since you're opening a new window, this is not a redirect anymore ... (and you might have some problems with popup blockers too).

Mda ... solved it. Pretty stupid of me.

I used the progressRender="true" stuff since I use a progressbar and because of this I hadn't declared my controller as Renderable anymore. I made it Renderable and now the messages are shown correctly. (Should have been pretty straight forward, considering upload takes place asynchronously).

Hi there,

I have the following:
<ice:inputFile id="inputFile" actionListener="#{uploadController.fileUploaded}" 
 					progressListener="#{fileUploadProgressListener.progressMade}" progressRender="true" />


public void fileUploaded(ActionEvent event) {
 		InputFile inputFile = (InputFile) event.getSource();
 		if (inputFile.getStatus() == InputFile.SAVED) {
 			FileInfo fileInfo = inputFile.getFileInfo();
 			FacesUtils.info("File uploaded");
 			log.info("I uploaded " + fileInfo.getFileName());

Where the FacesUtils.info does this
public static final void info(String summary) {
 				new FacesMessage(FacesMessage.SEVERITY_INFO, summary, null));

My problem is that the messages don't get displayed each time I upload a file. Only seldom. Any ideas?


Check the component showcase (on-line or run it local) and check component behavior. Then you'll be able in the same page to check the jspx and java code for that specific page. This will save you a lot of trouble and time spent on the forum.


I met the same problem. I have this SearchController which returns some results, and the dataTable holding the results should be sortable according to different criteria.
One of the "wrong" things is that the "action" methods on the command sort headers are called before the backing bean gets the selected column and the ascending/descending flag set. The workaround is to make a Phase Listener and resort the results depending on the current flags.
Of course I met the same behavior when trying to use the f:phaseListener (it's not called on the first display of the page and also never for APPLY_REQEST_VALUES and RENDER_RESPONSE) and I did a workaround using the standard PhaseListener approach (registered in faces-config). Then it occurred to me that I shoul give it another try and I made an init method annotated with @PostConstruct where I manually add "this" (being the controller) to getFacesContext().getViewRoot()'s phase listeners. And guess what?
It doesn't work. It has the same stupid behavior like f:phaseListener.
So I'll stick to the faces-config phaselistener for now ... trying to minimize the evil.

Don't wanna offend you, but this ain't in my opinion the best approach.

First of all, you should try to separate concerns: you have an entity - Book, a database service - BookService ... why don't you also create a controller - BookController; things will become much clearer. In this controller you can have a field - Book book ... Now, on the controller's addBook method you could do something like :
public void addBook(ActionEvent actionEvent) {
  	try {
  		book = new Book(); 
 		// or book = null, depending on how you design 
 		// your interface / behaviour			
  	} catch(Exception e) { 

The problem in your code was not about how you define the id mapping, but about trying to use save on beans which already had an id set (after the first save call).

Also, a little bit off-topic ... since you close your sessions by hand in that finally block, use openSession() instead of getCurrentSession(). The latter was designed for context propagation (when it's not the Book service the one taking care of managing the Session, but some higher level - check on the net about OpenSessionInView pattern). Things work for the moment in your case (since getCurrentSession will always create a new Session) ... but they will start breaking soon in case you change your programming pattern or forget to close a Session.

Eduard Korenschi
Profile for edykory -> Messages posted by edykory [319] Go to Page: Previous  1, 2, 3 , 4 ... 20, 21, 22 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team