ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Honnestly I don't know. I've never used it in Portlets. Perf was always fine enough for my needs.

My post is 2 years old now. I must say that, since then, I prefer RichFaces.

I switched from Ice to Rich as my framework of choice in late 2007, mainly for compatibility reasons with JSF 1.2 at the time. I stuggled because the IceFaces forum was much more helpful than the RF one (they got more friendly with time).

There was also the (posssibly wrong) feeling of always being able to solve any given issue with RichFaces. The drawback is the extra xhtml code (a4j:support, etc) compared to IceFaces which does all the process'n'refresh automatically. The usual story of flexibility vs simplicity.

Now don't take me wrong, if a customer asks me what Ajax-JSF framework to use in JEE, I always mention IceFaces together with RichFaces, and he can choose. They are really similar and one can achieve the exact same result in the end. One is backed by SUN, the other by JBoss, there's a reason for that: Both are really high quality frameworks.

Beyond that, there are alternatives: GWT, Flex, etc...thihs is a long debate. But when it comes to full EE Web development, i'll choose either IceFaces or RichFaces. Nothing else.

Seems this issue is now acknowledged
http://www.icefaces.org/JForum/posts/list/5007.page

And some more explanation
http://www.icefaces.org/JForum/posts/list/5137.page

If I understood well, all form inputs are always submittted on some ajax request, just like in RichFaces when you provide <a4j:support /> alone. I can compare actually cause I'm using RichFaces at work and IceFaces at home.

Actually I've been wondering why we have such a situation in IceFaces, even using the attribute "partialSubmit", whereas the much similar "ajaxSingle" attribute solves all your problems in RichFaces. I haven't checked the code, but they must be dealing with the JSF lifecycle in different ways with their ajax submits.

This is a matter of trade-offs after all. Indeed, IceFaces aims at providing a real event oriented UI and what's hidden behind the "Direct to Dom" thing actually NEEDS all form values to be submitted in order to know what to update in the view. On the other hand in RichFaces, the ajaxSingle thing solves your on-the-fly validation problems but the drawback is you don't always see in the view what's in your model...

In conclusion I'd appreciate an improved partialSubmit behavior, as it's written on the thread I mentioned before.

Noone ? Am I the only one to have this issue ?

Config: IceFaces 1.6.0, Tomcat 5.5.23, JDK 1.6.0_02

I have a form with, in this order :
- an ice:selectInputText with a valueChangeListener
- several ice:inputText
- an ice:selectInputDate with renderAsPopup="true"
- an ice:selectOneRadio with partialSubmit="true"

All of them have required="true"

Hang on:
1.1) As noted here http://www.icefaces.org/JForum/posts/list/4927.page, validators for required values all fire when I click on the little calendar in order to open the selectInputDate popup. Fortunately it does not prevent from actually selecting the date.

1.2) However, IF immediate="true" on the selectInputText THEN it becomes impossible to select a date in the selectInputDate !

2.1) Let's go back to the initial config. Do not fill all required fields preceding the selectInputRadio. Upon selection of one of its items, all validators are triggered for all yet required fields (until now, just like with the selectInputDate, but without the immediate thing). Unfortunately, the value is not set in my managedBean although the selectInputRadio's paritalSubmit="true" (i also tried to add immediate="true", same thing).

2.2) Let's fill all required fields preceding the selectInputRadio, or remove the required="true" attributes. Now the partialSubmit works perfect !

2.3) Now let's replace the selectInputRadio with a selectOneMenu: you won't be surprised to experience the exact same thing.

I can't tell as for 1.x, but 2.x were already in v1.5.3.

I can work around all that easily (all required="false" and selectInputTexts immediate="false", testing values upon submit) but I suspect there are one or two bugs here.

Personnally my jspx are like that under 1.6.0 :

Code:

 <?xml version="1.0" encoding="UTF-8"?>
 <jsp:root version="2.0"
 	xmlns:jsp="http://java.sun.com/JSP/Page"
 	xmlns:f="http://java.sun.com/jsf/core"
 	xmlns:h="http://java.sun.com/jsf/html"
 	xmlns:ice="http://www.icesoft.com/icefaces/component">
 
 	<f:loadBundle basename="fully.qualified.class.name.bundle" var="msg" />
 
     <ice:outputDeclaration doctypeRoot="HTML"
         doctypePublic="-//W3C//DTD XHTML 1.0 Strict//EN"
         doctypeSystem="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"/>
 
 	<f:view>
 	<html xmlns="http://www.w3.org/1999/xhtml"> 
 
     <head>
         <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></meta>
 		<title>Hello world</title>
 		<link rel="stylesheet" type="text/css" href="./xmlhttp/css/xp/xp.css" />
     </head>
 
 	<body>
 	
 	<ice:form>
 
           [all your form stuff here]
 
 	</ice:form>
 
 	</body>
 	</html>
 	</f:view>
 </jsp:root>

Maybe it would help ?

Great job IceSoft-men, what an improvement over 1.5.3.

You should advertise like mad on Java/JSF news sites, I don't even see an announcement on JSFCentral.

Put yourselves in the light, on the headlines, for God's sake, you probably have the best Ajax-JSF framework out there, people need to know !

Kranthi_543 : Yeah I got this issue too, definitely.

I haven't checked, but can you workaround it using immediate="false" ?

One point six !!!
One point six !!!
One point six !!!

Hi
I was updating my code with the new fileNamePattern attribute of InputFile, when I encountered this error message :

Le 'DSCN1457.JPG' de nom de fichier pas allumette avec le '(?i)(.+\.jpg)|(.+\.png)|(.+\.gif)' de modèle de nom de fichier

Some "match" in english was translated here as "allumette", the ancestor of the lighter, which made me laugh a lot :)

The correct translation would be :
Le nom de fichier 'DSCN1457.JPG' ne correspond pas au modèle de nom de fichier '(?i)(.+\.jpg)|(.+\.png)|(.+\.gif)'

Yeah, I agree, but as I said, we can expect a lot of people to backup the other, so maybe it's time to advertise IceFaces more, all th emore as v1.6.0 is out anytime now.

and #{myBean.address} evaluates to what value ???

Ah yes I understand now, that's a classical one : when a field is empty (i said empty, not blank), and if the component tag doesn't specify required="true", then your validator will never be called.

I remember of this issue being discussed with Ed Burns on a JSF RI impl discrepancy report somewhere on the internet.

The validate method signature is actually
Code:

public void validate(FacesContext context, UIComponent component, Object value) throws ValidatorException

, but you obviously did like that or you wouldn't be compliant with an impl of javax.faces.validator.Validator.

Well, apart from that, if your validator is just declared and has no specific tag associated to it, you should have something like that in your faces-config.xml :
Code:

 <validator>
   <validator-id>MyValidatorId</validator-id>
   <validator-class>fully.qualified.class.name.MyValidator</validator-class>
 </validator>

And in the JSP you should have something like :
Code:

 <h:inputTextArea value="blah blah">
   <f:validator validatorId="MyValidatorId"/>
 </h:inputTextArea>

or
Code:

 <h:inputTextarea value="blah blah" validator="MyValidatorId"/>

This is not related to IceFaces, but I hope this helps.

Could you provide some example ?