Messages posted by: carlo.guglielmin  XML
Profile for carlo.guglielmin -> Messages posted by carlo.guglielmin [63] Go to Page: 1, 2, 3, 4, 5 Next 
Author Message
The easiest approach is to put these files under WEB-INF/, since


will return a 404.

A common practice is to have:


For example.
You should be able to increase the session timeout in your app server. For example in Tomcat you can add this to the web.xml:

A second approach is more to hide the problem, and that is to disable the built in error popups ICEfaces uses. Again in web.xml you can


You can see the full list of configuration options at: http://www.icesoft.org/wiki/display/ICE/Configuration

A final option is to force some kind of session ping from your client to "fake" user activity and keep the session alive.
Using Ajax Push in this case should be doable, depending on how the data is displayed. How do you render the checkboxes in the content of the panels?

Generally you would have a placeholder "Loading..." text in the panel when the user first visits the page that is controlled by some kind of "isLoaded" boolean flag in the backend. From the bean you'd start a new Thread to do your LDAP lookup. When this Thread completes and is done processing the data you'd toggle the "isLoaded" flag and set in your data and then perform a Push. In the client browser they would see the "Loading..." text disappear (since the flag was switched) and the data populate (since you just set it in).
Hi Karthikayan,
I'd recommend the ICEsoft Showcase (http://icefaces-showcase.icesoft.org/) to see the latest component demos. You can get the source code very easily under the samples/ directory in the ICEfaces download bundle.
There are a couple other demos available under http://www.icesoft.org/demos/icefaces-demos.jsf
Glad you like it. All we're doing is displaying an ICEfaces panelPopup with fields for username and password. Then when the user clicks submit we process the login in an actionListener. Pretty simple really and very easy to replicate using standard components.
OutputLabel should only be used when you're associating it with a field, otherwise just use OutputText.
As for scrolling you could wrap the OutputText in a div or panelGroup with a set height and the overflow property set.
Instead of relying on IDs, what about just exposing a mock web service from your ICEfaces application that your PHP app can call, likely through a POST?

Something along the lines of:

Then just redirect PHP to that page when you need to login? Of course you wouldn't use an exposed GET like above, but I'm sure POSTing from PHP wouldn't be a problem.
Then the "remote-login.iface" page just grabs those parameters and does the backend work you need.

I think that might be a bit cleaner than trying to hardcode IDs and simulate a button click.
You can use a few approaches (where "key" would, in your example, be a String containing "area"):

Map<String,String[]> requestMap =

Instead of hassling with scopes I normally maintain a couple of variables in an extended request scope or session scoped bean. The variables are checked and lists are created from URL params based on a hidden getter in the page. Something like this:

private boolean hasCheckedParam = false;
 private String currentParam = null;
 public String getHasCheckedParam() {
     if (!hasCheckedParam) {
         currentParam = FacesUtil.readParameter("key");
         if (currentParam != null) {
             hasCheckedParam = true;
             refresh(); // Reload the page so the param goes away but the data remains loaded
     return null;

    <ice:outputText value="#{bean.hasCheckedParam}" style="display: none; height: 0;"/>

What happens is the outputText will call the getter which will read the parameter "key" (if it hasn't already) and try to load some data based off it. You can do more checks on the parameter (length, format, etc.) and customize how often you want it to check (in terms of using the boolean flag or not).
But the main point is this getter will be called a bunch of times, so you can check the parameter all you want and load all the data you need without worrying about the constructor.

Hopefully that helps.
Rendered is a flag used by the JSF component tree during it's creation, so you won't have any control from the client side. The closest you could get would be setting the style to "display: none;" by Javascript. The third result when trying to search with that in mind gave me this page which should start you in the right direction.
Glad to hear f:attribute passed fine. The error you pasted looks database related, so I'd double check your persistence layer to see what's going wrong.
Look into the saveOnSubmit attribute? If set to true then pressing a command button in the same form as the inputRichText will cause it to be submitted just like a normal text field.
Wow some real thread necromancy going on, 2008 to 2010 to 2011.

Anyways selectOneMenu is mostly left to the browser, so you don't have a lot of control over how many items are shown. Perhaps consider using selectInputText (Autocomplete) instead? You can limit that to a number of displayed rows. Or if you want more than single item to be shown at once use selectOneListbox with the size attribute specified (perhaps to 2).

hockey9876 wrote:
Here's a link I found to be quite helpful:


I've used it in working through some of the components. 

The facestutorials index is slightly out of date, I'd recommend checking out the Tutorial list on the main site instead.

I don't know what version you're using, but our ICEfaces 2.0 tutorials are much newer and easier to understand. You can find them on our wiki.icefaces.org site. There are examples for each of the topics you mention: Ajax Push (not Ajax Poll, that's some confusion that reading on ICEpush might help), Data Table, Drag and Drop, and Tree. Some are just updates to the 1.8 tutorials, but a lot are new docs from the ground up.
The scenario you describe depends a lot on the code you're using. Is the textarea bound to a String in a bean? What is the scope of the bean? If both the textarea and selectOneMenu are bound to an extended request or session scoped bean then they shouldn't clear once entered.
Profile for carlo.guglielmin -> Messages posted by carlo.guglielmin [63] Go to Page: 1, 2, 3, 4, 5 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team