ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hello,
after a first integration of ICEFaces in a JSF application I need some help/advice on how to tune it. The main need in ICEFaces is to get AJAX Push. I am also using compat jar as I need GMaps in my app. I haven't been able to include these maps with direct javascript (ICEFaces Push seems to inhibit direct javascript in my pages) or Gmaps4JSF solution.

1) I have RequestScoped, ApplicationScoped and SessionScoped backing beans for JSF h:forms. I only need Push in Session and Application ones as Request ones are used to create new items and so its info should not be updated. (I cannot use ViewScoped as I use CDI Injection and won't work with it) Is there any way to "remove" these from all the push environment. I don't have a clear picture if ICEFaces refreshes the whole HTML or acts only against h:forms with back beans that do have new content. I'm concerned about this because I see the app very slow after including push.

2) Do I have to invoke PushRenderer.addCurrentSession("ID"); in every bean constructor or just once?

3) When I use ICEFaces application turns very slow. Mozilla also turns slow. JSF h:commandLink links some times take 20 or 30 seconds to get invoked in the backing bean and gets slower as time passes. Are there any "good practices" on how to structure h:forms and/or backing beans to improve application response

4) Also, things like "onchange="submit()" in h:selectOneMenu also seem to only work in the first moments of the app. After a while they stop working. As I am using compat-library do I have to use ice:selectOneMenu?

5) I use ui:composition for templating. Is there any good practice on this or I can use it right as if there was no ICEFaces?

6) I see in docs that ice:form should be used when using compat library. I use it to get gMaps support. Do I need to replace all h:form in the app or just h:form in the ui:composition that is using ice:gMap tags?

7) As told before. <script> javascript's in my HTML code don't seem to be executed when using compat-library. Can I solve this? I need this javascript, for example, to add polylines to a ice:gMap

Thanks for any help/directions on any of these points,
Ignacio

icordoba wrote:

1) I have RequestScoped, ApplicationScoped and SessionScoped backing beans for JSF h:forms. I only need Push in Session and Application ones as Request ones are used to create new items and so its info should not be updated. (I cannot use ViewScoped as I use CDI Injection and won't work with it) Is there any way to "remove" these from all the push environment. I don't have a clear picture if ICEFaces refreshes the whole HTML or acts only against h:forms with back beans that do have new content. I'm concerned about this because I see the app very slow after including push.

2) Do I have to invoke PushRenderer.addCurrentSession("ID"); in every bean constructor or just once?

The bean (and it's scope) that you call PushRenderer.addCurrentSession("myRenderGroupName") is not the critical part. What the call does is add the current user session to the render group identified by the string parameter. Once it's added once, you don't have to add it again for that session as long as it's active and isn't removed. So the short answer is, you generally only have to call it once.

When you call PushRenderer.render("myRenderGroupName"), all the active sessions added to that group will have an Ajax Push request triggered. The Ajax Push basically just triggers a client side request automatically, running the JSF lifecycle and returning updates. By default, ICEfaces does a render=@all operation where changes to the entire page are detected and sent back to the client.

3) When I use ICEFaces application turns very slow. Mozilla also turns slow. JSF h:commandLink links some times take 20 or 30 seconds to get invoked in the backing bean and gets slower as time passes. Are there any "good practices" on how to structure h:forms and/or backing beans to improve application response

It might help us if you could post a small sample application that shows the slow behaviour as that doesn't sound typical. Is there database access involved? Large data tables of some kind?

4) Also, things like "onchange="submit()" in h:selectOneMenu also seem to only work in the first moments of the app. After a while they stop working. As I am using compat-library do I have to use ice:selectOneMenu?

Again, a sample app may help here as it doesn't sound like proper behaviour. You don't have to use the ice: components but you can get the benefit of using partialSubmit when using the ice: version which can improve performance.

5) I use ui:composition for templating. Is there any good practice on this or I can use it right as if there was no ICEFaces?

There shouldn't be any problems with using ui:composition with ICEfaces.

6) I see in docs that ice:form should be used when using compat library. I use it to get gMaps support. Do I need to replace all h:form in the app or just h:form in the ui:composition that is using ice:gMap tags?

Just the forms that use any ice: components.

7) As told before. <script> javascript's in my HTML code don't seem to be executed when using compat-library. Can I solve this? I need this javascript, for example, to add polylines to a ice:gMap

How is the JavaScript code added to the page? Is it just inline in the page or are you adding it dynamically somehow?