ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

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:
http://localhost:8080/someIceApp/remote-login.iface?username=bla&password=test

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"):

Code:

Map<String,String[]> requestMap =
 ((HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest()).getParameterMap();
 requestMap.get(key);

or
Code:

((HttpServletRequest)FacesContext.getCurrentInstance().getExternalContext().getRequest()).getParameter(key);

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:

Bean:
Code:

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

Page:
Code:

    <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.

The PushRenderer PortableRenderer is indeed what you want. You might just be setting it up or using it incorrectly. Try something like this:

Code:

 public void startLongProcess(ActionEvent event) {
     final PortableRenderer renderer = PushRenderer.getPortableRenderer(FacesContext.getCurrentInstance());
     new Thread(new Runnable() {
         public void run() {
             doSomething();
             renderer.render("someGroup");
         }
      ).start();
 }

Not too crazy, just make sure you can get a valid FacesContext instance when you initialize the PortableRenderer and you shouldn't have a problem. See also the Ajax Push docs for more details.

Also to your question about whether you can do a Push from the server or only when the client initiates, well, of course you can Push from the server, that's the whole point :) Basically Ajax Push allows you to send updates from the server to the client at any point, without them having to hit refresh or manually update the page. Handy for asynchronously populating a huge dataTable or updating one client based on what another client does, etc.

It sounds like you have some threading going on? In that case try getting an instance of a PortablePushRenderer instead of calling the static method. That way you can pass in a FacesContext instance, THEN start your thread and use the PortablePushRenderer instead of trying to get the FacesContext from inside your thread. See the Ajax Push docs for details.

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:

http://facestutorials.icefaces.org/tutorial/index.html

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.

Hi,
Just make sure that the value bound to the selectManyCheckbox doesn't match any of the selectItems, and by default none of them will be checked. You can even have the value default to null and then force the user to check what they want.

Definitely a common use case. You'll probably want to use f:attribute and grab it from the ActionEvent in your bean.

In your page:
Code:

 <ice:dataTable value="#{myController.list}" var="currentVal">
 ...
 <ice:commandButton value="Edit" actionListener="#{myBean.performEdit}">
     <f:attribute name="toEdit" value="#{currentVal}"/>
 </ice:commandButton>
 ...
 </ice:dataTable>

And then in your bean:
Code:

 public class MyBean {
 ...
     public void performEdit(ActionEvent event) {
         MyObj edit = (MyObj)event.getComponent().getAttributes().get("toEdit");
     }
 ...
 }

Basically the "MyObj edit" ends up being set to the value of "#{currentVal}" from the page. Of course you'll want more checks in place (like ensuring the retrieved object is valid before casting it, and probably having the name "toEdit" pulled from a single place instead of hardcoded in both the bean and page).

Note you can also try f:param or f:setPropertyActionListener (my favorite and sorely underused).