Forums de discussion

Adding Icefaces jars break bridge:inputFile.

Wim van der Vegt, modifié il y a 11 années.

Adding Icefaces jars break bridge:inputFile.

New Member Publications: 7 Date d'inscription: 08/07/10 Publications récentes
Hi

I tried to convert a icefaces3 portlet to standard jsf as much as i can but ran into the following problem.

The moment the 3 icefaces3 jars (v3.1.0) are added to a jsf2 project (you can copy the jars from the icefaces3 demo to the jsf2 demo), the bridge:inputFile tag no longer calls its fileUploadListener at all. It's not neccesary to use any icefaces in a jsf2 page or add the icefaces namespaces for the problem to occur.The bridge version is 3.1.1-ga2.

regards
Wim van de Vegt.
thumbnail
Neil Griffin, modifié il y a 11 années.

RE: Adding Icefaces jars break bridge:inputFile.

Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
The bridge:inputFile component tag is very Web 1.0, meaning it requires a full page postback. I think that adding ICEfaces jars to a project will auto-ajaxify all forms. When you try to upload the file, does it invoke the portlet ACTION_PHASE (full postback) or the RESOURCE_PHASE (ajax postback)?
Wim van der Vegt, modifié il y a 11 années.

RE: Adding Icefaces jars break bridge:inputFile.

New Member Publications: 7 Date d'inscription: 08/07/10 Publications récentes
Hi Neil,

I assume iceface does something but fail to see why it's loaded when it's not used in the jsf page at all.

I now also see failures in some f:ajax event calls when a icefaces tag is present. I need to move those back to the commandButton as actionevents.

And simple (java) <script> tags inside a panelgroup that is made visible by clicking a button is not executed anymore when icefaces is present (it works nicely with pure jsf2).

regards
Wim van der Vegt
thumbnail
Neil Griffin, modifié il y a 11 années.

RE: Adding Icefaces jars break bridge:inputFile.

Liferay Legend Publications: 2655 Date d'inscription: 27/07/05 Publications récentes
Hi Wim,

When the ICEfaces JARs are present in the ClassPath, the JSF runtime will scan the META-INF/faces-config.xml files for things that are supposed to be registered. ICEfaces registers its own decorator factories that help the ICEfaces framework function properly:

<factory>
        <faces-context-factory>
            org.icefaces.impl.context.IceFacesContextFactory
        </faces-context-factory>
        <partial-view-context-factory>
            org.icefaces.impl.context.DOMPartialViewContextFactory
        </partial-view-context-factory>
        <exception-handler-factory>
            org.icefaces.impl.application.ExtendedExceptionHandlerFactory
        </exception-handler-factory>
    </factory>


It might be the case that one or more of these factories participate in the JSF lifecycle such that they all JSF views are effected.

Best Regards,

Neil