Messages posted by: patrick.corless  XML
Profile for patrick.corless -> Messages posted by patrick.corless [1939] Go to Page: Previous  1, 2, 3 ... 127 , 128, 129, 130 Next 
Author Message
If you want to change the default style of the upload button you must assign a CSS class the the file upload component.

This is done by adding the attribute "buttonClass" and assigning a class it it. For example:


The default style class is defined as, any of these attributes can be over ridden with your own styleClass.

.iceFileUploadButton {
     border: 1px solid #ABABAB;
     background-color: #FFFFFF;
     margin: 2px;
     padding: 2px;
     font-family: Arial, Helvetica, sans-serif;
     color: #000000;

Whether your using an ICEfaces component or an HTML anchor tag, colour changes can be made via CSS.

Assume the following common methods of creating links in JSF, pay particular attention to the styleClass and class attributes.

<ice:commandLink styleClass="myCustomLinkStyle" 
     <ice:outputText value="My Link 1"/>
 <ice:outputLink styleClass="myCustomLinkStyle"
          <ice:outputText value="My Link 2"/>
 <a class="myCustomLinkStyle"
      My Link 3

The styleClass and class attribute values all point to the same CSS class name. The style class would be define in CSS like this:
 <style type="text/css">
 .myCustomLinkStylenodec {
    color: #333366;
    font-family: Arial, sans-serif;
    font-weight: none;
    font-size: 11px;
    text-decoration: underline
 .myCustomLinkStyle:link {
    color: #333366;
    font-family: Arial, sans-serif;
    font-weight: none;
    text-decoration: underline;
    font-size: 11px;
 .myCustomLinkStyle:visited {
    color: #333366;
    font-family: Arial, sans-serif;
    font-size: 11px;
    font-weight: none;
    text-decoration: underline
 .myCustomLinkStyle:hover {
    color: #666699;
    font-family: Arial, sans-serif;
    font-size: 11px;
    text-decoration: underline;
    font-weight: none;

In class declaration ".myCustomLinkStyle:hover" is where you would want to define what happens when the mouse is over it.

I suspect that you may not have setup an id binding to a dataTable component. Here is a typical usage case.

The dataTable must have an id associated with it.
 <ice:dataTable id="my_pagable_dataTable"

It is very important that the paginator references the dataTable by id.

     <ice:outputFormat {2} to {3} of {0}, page {4} of {5}." >
         <f:param value="#{rowsCount}"/>
         <f:param value="#{displayedRowsCount}"/>
         <f:param value="#{firstRowIndex}"/>
         <f:param value="#{lastRowIndex}"/>
         <f:param value="#{pageIndex}"/>
         <f:param value="#{pageCount}"/>

And lastly make sure your dataTable has a rows attribute set or the paginator will not know how many rows are to be shown on a page.

I hope this helps.
We've seen this on some of our sample applications. The problem is related to an iframe that is added to the header of the page by the framework. This issue is still being looked at by the framework team.

There is a work around but it can not be used is Safari is a supported browser for you application. The fix is pretty simple css tweak.

   display: none;
   border: 0;
   margin: 0;
   padding: 0;

Hi Criag;

Thanks for the information. I suspect that state.render is being called a little to frequently and as a result is filling up the queue. Maybe you can add some timing debug code to your upload loop to make sure that the calls to state.render have one or more seconds between each call. If your calling it more then a couple times a second you'll must likely start seeing queue errors.

I mentioned earlier that the queue overflow error usually doesn't cause any problem. It does however usually mean that the session has gone away and the client is no longer answering or there is a network problem that is interrupting the push in some way.

The following code snipet shows how to handle the Renderable interfaces renderingException method. If the queue over flows it usually results in a TransientRenderingException. When a session has expired or some serious error occurs then a FatalRenderingException will be thrown. If you ever use one of the RenderManger instances it is a good idea to remove the instance of the Renderable class from the RenderManager on a FatalRenderingException.

public void renderingException(RenderingException renderingException) {
     if (log.isDebugEnabled() &&
             renderingException instanceof TransientRenderingException) {
         log.debug("Transient Rendering excpetion:", renderingException);
     } else if (renderingException instanceof FatalRenderingException) {
         if (log.isDebugEnabled()) {
             log.debug("Fatal rendering exception: ", renderingException);
         // not applicable to your usage case, but good to know for future
         // developement. 
Hello Craig;

The runtime exception may not be problem in your particular case. This error message usually shows up if your using the Render Manager to send server initiated pushes.

So why the errors? Well they can usually indicate that a network issues or a session that has gone away.

Please let me know if your using the render manager and I can post some code and explain this further.


Could you post your jspx for this problem and double check that your input text is surrounded by an <ice:form></ice:form> component.
Please visit http://www.icesoft.com/products/icefaces_services.html
The problem is do to the jsx:include call. For ICEfaces to correctly handle the JSF include you have to use the following tag.

<jsp:directive.include file="/chat/chat_client.jsf" />

All should be good one you make this change.
We've been using this javascript trick to pre-load images for the browser. It should help in most cases assuming the web server is correctly setting the header information for images. If this doesn't help let me know as there is also a way to use a filter to help insure that image headers are correctly set by the webserver.

Put this code towards the end of your page content.

<script language="JavaScript" type="text/javascript">
     //    <![CDATA[
     var preloaded = new Array();
     function preload_images() {
         for (var i = 0; i < arguments.length; i++) {
             preloaded[i] = document.createElement('img');
             preloaded[i].setAttribute('src', arguments[i]);
     // images to be pre-loaded by browser
     // -->
     //    ]]>


It's hard to tell exactly what's going on with out a snapshot your jspx code. But assuming your code was working in JDeveloper and no it doesn't in Eclipse I suspect it is a dependency problem.

Make sure you have the following jars are being copied into your deployment directory for eclipse.

Facelets Support

General JSF/ICEfaces jars

We don't have any know bugs surrounding message bundles. Maybe you can give me a little more information about how you have the bundles setup in your project.

In component-showcase we setup our message bundles as follows:

    var="msgs" />

Where com.icesoft.icefaces.samples.showcase.resources is the package name of where the message bundles are stored. The actual message bundles start with the name "messages" and JSF/Java adds the appropriate extension. However you need to have the default file, in this case messages.properites.

If you are still having problems let me know what kind of environment your running you application under.


I came across the same problem with converters. The problem has been fixed and will likely make the next developers release.

If your convert converts from String to String it will currently not work but if your converter converts from String to some other Object the converter will work as expected. The String to Sting conversion fix will be in the next release.

Your very close to getting sorting working. The bean attributes corresponding to:


The above bindings are updated when the headers are clicked, this maintains state but doesn't actually do the sorting.

When the MessagesBeans getRowsDataModel is called you'll have to decide if you want to sort your list based on the sortColumn and sortAscending values. I would recommend you use the notion of an oldSortColumn and oldSortAscending to determine if a sort is really needed.

It is also possible to use a PhaseListener instead of the getRowsDataModel as a sorting trigger.
Your example should refresh the stacking panel as you suspect but there is a subtle problem with the jspx code.

Most browser to not know how to handle embedded form tags. The ICEfaces bridge code will also act unpredictably. Remove the second ice:form tag from the 1.jspx and I suspect you button will start working.
Profile for patrick.corless -> Messages posted by patrick.corless [1939] Go to Page: Previous  1, 2, 3 ... 127 , 128, 129, 130 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team