| Author |
Message |
|
|
Take a look at the auction and auctionMonitor demos included with the ICEfaces bundle.
All you need to do is add your user to the group for updates: <icecore:push group="tweets" /> in your page and PushRenderer.render("tweets"); in your bean when the string is updated.
|
 |
|
|
ICEfaces will render the entire page, but will only update the parts that have changed.
You can invoke JavaScript with either the JavascriptRunner API or an ICEfaces onAfterUpdate.
http://wiki.icesoft.org/display/ICE/JavaScript+Client+API
|
 |
|
|
ICEmobile emphasizes a server-side application that has access to native device capabilities, so this means arbitrary pages on the server that Apple did not review at the time of App submission (because they are part of your application). This is in contrast to a phoneGap application that contains all pages pre-packaged in the application for App Store review.
|
 |
|
|
Perhaps the naming of the page in a configuration file -- EASTLogin.xhtml vs Login.xhtml?
|
 |
|
|
|
Which version of mojarra do you see logged during the startup of your application? This could easily be a mojarra bug that is currently fixed.
|
 |
|
|
|
JSF saves the view automatically, so you should not need to call this from your bean. If you have saved the .xls to the file system, it should just be a matter of moving the file into the webapp directory and generating the right URL to pick it up in the user's browser.
|
 |
|
|
Are you using the version of JSF included with JBoss or .jars in the application. Would it be possible to create a small test case and attach it to the JIRA? If you deploy the same application to tomcat, do you see the same problem?
It looks like the combination of ice and ace components is interacting strangely with the autoid feature, you could try setting org.icefaces.autoid to false in your web.xml.
|
 |
|
|
Do you have .xhtml mapped to the FacesServlet? The extension must match the servlet-mapping.
|
 |
|
|
|
The f:ajax tag is not necessary -- ICEfaces automatic ajax will update the media link without it. You may also need to set the player attribute.
|
 |
|
|
Do all browsers play the mp3 if you paste the URL into the URL bar?
|
 |
|
|
It's almost always better to use the simple value attribute rather than a component binding. When the page is rendered, ICEfaces will determine that just the URL for the mp3 file has changed and update just that part (this is not affected by whether you use the binding or the source value).
|
 |
|
|
Which version of ICEfaces are you using and what servlet-mapping patterns do you have for the BlockingServlet? Removing the servlet is not a tested configuration, but as long as you have /xmlhttp/* mapped to PersistentFacesServlet, the BlockingServlet should not be necessary.
http://res.icesoft.org/docs/v1_8_2/htmlguide/devguide/references5.html
|
 |
|
|
|
ICEpush is highly scalable because it does not handle data at all -- with ICEpush you notify the browser, and it fetches the data using any mechanism you prefer. In ICEfaces, this is abstracted for you with the PushRenderer which uses the JSF lifecycle to determine ajax page updates, but you can use ICEpush even with, say, Servlets, with or without sessions.
|
 |
|
|
The logging has been improved to include the stack trace:
http://jira.icesoft.org/browse/ICE-8016
Is it possible for you to check out ICEfaces 3 from the trunk and test?
|
 |
|
|
JSF 2 does not generally support JSP inclusion, although we do have a prototype project in ICEfaces-EE that will handle some cases. In particular, problems are encountered when JSF 2 attempts to add resources to the <head> of the document, such as jsf.js. If the JSP parts of the application are not extremely critical (for legacy reasons) the best approach is to reconstruct the JSP headers and footers in facelets and potentially have separate pages for the purely JSP parts.
|
 |
|
|