ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Can you provide additional details on your ICEfaces/portlet requirements?

- can ICEfaces portlet share a common session on the application server?
- must ICEfaces portlets support WSRP?
- must the portal page (including the portlet controls) be ICEfaces-enabled?
- are the requested portal servers absolute requirements?
- how should connection status be displayed (for application-initiated update)?
- to what degree will the portlets interact with each other (i.e. if the user interacts with one portlet, are the others expected to be updated)?

We're looking for Portlet-enabled components as well. I can answer some of these questions based on my own requirements:

-yes, multiple portlets will share a common session, this is how portlets work
-we do not need WSRP support
-the portal page itself (i.e. the WebSphere Portal or Liferay or StringBeans portal screens) do not need to use ICEfaces components, just the portlets themselves (did I understand this question correctly?)
-we are using Liferay 4.1, we would consider eXo as well
-portlets are independent in our implementation (one portlet does not need to listen to another)

What is the timeline for the portlet integration?

Hi,

It's looking like early 2007 for a preliminary release. If you have any more detailed requirements on Portlet integration (preferred Portal implementation etc.) please let us know.

Thanks,
Philip

Hi,

Is ICEFaces 1.5 support jsr 168 portlet?

Erwin

Hi Erwin,

No, ICEfaces 1.5 does not yet fully support Portals. We have some initial support in this version, but there's still some work to do on this. We should have Portal support sometime in Q1 2007.

Thanks,
Philip

Hi
I'd also like to register my interest in a portal version of ice faces. Our IT department is looking at standardising on ICE Faces. We have a mixture of straight browser apps along with an intranet running on WebSphere Portal.

we don't need WSRP, our portal page doesn't need ICEFaces, but our portlets do. Portal interaction will be through the Shared Application Portal Session scope as defined in the JSR168 Spec

Regards
Nimai Etheridge

Hi

We're currently in the early stages of developing a jsf/ajax application and are very interested in utilizing ICEfaces. We have been developing a portal solution using Liferay for several months now and hope to go live by the end of this year. My current project, as well as the other systems we have built, will be getting moved in some way shape or form to the portal beginning sometime in Q1 07. I'm hoping our development can coincide with your release of a portal capable version of icefaces - and it looks like it just might. I will be discussing this with my team next week, at which point I will be able to post some more detailed requirements. If you have any specific questions I can answer (outside of ted_g's initial set) please let me know.

Thanks!

I would like to weigh-in on this issue as well, and encourage the IceSoft folks and IceFaces community to support JSF portlets.

I manage our corporate portal, which is based on Liferay 4.1.0 and JSF. Because MyFaces Tomohawk is dependent on the MyFaces filter, it is impossible to use Tomohawk within portlets, because JSR-168 portals do not support filters.

Because of this, I had to develop a suite of JSF components to do ordinary things (DataTable, FileUpload, etc..) but none of them are AJAX enabled. So rather than AJAX-ify my own components, I would much rather migrate to IceFaces.

BTW, the FileUpload component I developed uses a PhaseListener to intercept the enctype="multipart/form-data" from the request. I had to do it this way because the typical FileUpload JSF component makes use of a filter (like Tomahawk). Again, filters don't work with portals, so these are the types of things we have to deal with. I have attached the relevant Java files to this post.

So since I have a lot of experience in this area, I would like to offer my services to the IceFaces community in order to get IceFaces and portlets working together, especially in conjunction with Liferay. I'm sure there are many JBoss portal folks out there too who would love to use IceFaces too.

Regards,

Neil Griffin
Triton Services, Inc.

Hi,

What is the status about the Icefaces integration in portlets? We need to move a standard JSF web app using icefaces to a portlet.

Thanks,

Daniel Messer

Previous versions of ICEfaces had limited portlet support but we're working to make it much easier to use ICEfaces for portlet development in 1.6. The framework in the 1.6 codebase has undergone some significant changes to help make it easier to integrate with other technologies like portlets and Seam. Although I can't commit to any firm dates, we're hoping to provide an initial drop of the improved portlet support in the next developer release of 1.6 (around the end of March). For the official release of 1.6, our goal is to support the JSR 168 specification and have ICEfaces-based portlets running in JBoss and Liferay portal in the official 1.6 version of the product. We're definitely committed to supporting portlets in ICEfaces.

That's great news since we're using Jboss. Thanks for your effort.

Hi Deryk,

The 1.6 DR2 is now out - does this build contain fixes which will resolve the portal (esp Liferay) problems? If not, are there specific JIRAs which we should be watching for?

Thanks,

Jeff

It's not in this release and likely won't make the official 1.6 release which is due out in a few weeks time.

However, we are working on it and the likely scenario is that portlet support will be released against the 1.6 branch. The initial drop may be something like a separate early access download.

I don't have any firm dates but you will be able to run and test your portlet applications against 1.6 in the not too distant future.

Given that full portlet support won't be in 1.6 :-( , it would be very useful to have an idea of when this will appear. In particular, I am looking for support of WSRP JSR168 portlets (I'm tied to oracle portal) and really need to understand whether it is worth continuing to monitor this forum or not. (if we're looking at Q3/4 07, then for me, the answer is not)