Messages posted by: StormTAG  XML
Profile for StormTAG -> Messages posted by StormTAG [15]
Author Message
I have an IceFaces page which is powered by several Request scoped beans. When I make an initial GET request, I grab the external context via the faces context grab a GET parameter and use it to initialize my beans in their @PostConstruct method.

However, if I try to link to the same page with a different get parameter, it seems to be eating my request and treating it as a postback. None of the request scoped beans go out scope (exactly like they don't go out of scope on a post back) and the new value is ignored.

How do I get it to treat my link as a new request which needs new request scoped beans, etc.?
Unfortunately the only way I was able to do this was to remove all of the parental styling that had position:absolute. In my case this ended up simplifying the layout anyway so I managed to get away with it.

You might try putting the tooltips in a seperate file that you include outside of your position:absolute divs. Then you would need to ensure that the "tooltip" field matched what the div's ID field ended up being. You may have to prepend the JSF parent/form IDs.
As it stood, reworking the CSS so that it was outside of the position:relative div ended up vastly simplifying the existing layout anyway, so I'll call it a blessing in disguise.

Incidentally, if you have a developer who is very literal, giving him printouts of layouts made on word is not a good idea.
Wow. Learn something new every day. Didn't know there was such a colon syntax.
Hopefully a simple question, but is there any way to use a panelToolTip for a panelGroup that is inside another panelGroup/Div which has position:relative?
I'm pretty sure this is just me being retarded in some way, but I'm having an issue with prepopulating my selectOneRadio when using spread.

Here's a code snippet that works just fine! Notice the lack of spread layout...

<ice:selectOneRadio id="someRadio" value="#{ABean.radioValue}">
    <f:selectItem itemValue="1" itemLabel="A Label"/>
    <f:selectItem itemValue="2" itemLabel="Another Label"/>

ABean.radioValue int value is set to 1 in the constructor and when I render the above, the "A Label" is preselected. However, when I try to do the following...

 <ice:selectOneRadio id="someRadio" layout="spread" value="#{ABean.radioValue}">
    <f:selectItem itemValue="1" itemLabel=""/>
    <f:selectItem itemValue="2" itemLabel=""/>
       <td><ice:radio for="someRadio" index="0"/></td>
       <td> <b>SOME TEXT</b> </td>
       <td><ice:radio for="someRadio" index="1"/> </td>

...They render fine, function fine, but the SOME TEXT radio button is not preselected. Is there a bug in the spread that I don't know about or am I just doing something wrong?
Yeah, if I include the tool tip inside the panel group that will spawn it, it works fine. It's not how my original design was going to work, but I think I can work with that.


For any who come after and read this having any similar problems, IceFaces seems to throw null pointers if you try to add a Tooltip to a panelgroup when that tooltip is in another form.

This was the stack trace I was getting:

Guess I'm going to have to rework a lot of code, huh?
Just-ice.jar helped us, so hopefully it will help you guys out as well. You should probably check http://www.icesoft.com/developer_guides/icefaces/htmlguide/devguide/keyConcepts12.html to see if it will help you any.
I'm still a bit of an IceFaces noob, but I have been dealing with a conversion of raw JSF to IceFaces recently.

Remember that the IceFaces components use a fundamentally different renderer than most JSF libraries, the Direct to DOM renderer. That may not work with your existing JSF pages correctly. Ideally, you would refactor all of your webpages to IceFaces but if that's not possible, take a look at the Just-Ice.jar.

The Just-Ice.jar replaces your normal IceFaces jar and basically makes the D2D renderer play a little nicer with other JSF libaries. I use the JSF RI implementation with the JustIce.jar on my prototype at work.

http://www.icesoft.com/developer_guides/icefaces/htmlguide/devguide/keyConcepts12.html Check that page out for some more detailed information.

Hope this helps or at least sends you on the right path.

You could set them both to partialSubmit="true" and handle them as they happen, rather than waiting for a full-form submit.

Other than that, you can use one ValueChangeListener for both and use logic to determine which you're dealing with and whether or not you need to keep dealing with them (you can use the e.getComponent() to determine which is which)...

akearns wrote:

I would like to simulate the the user checking a checkbox if he changed another control in the same row or form.

I tried using the component showcase to determine what changes needed to be made.

In component showcase in the "Extended Components" Selection example
I tried to simply check the "New User" checkbox if the user changed their
car, drink or language.

I thought I could add: newUser=true

     public void effectChangeListener(ValueChangeEvent event){
     	newUser = true;

to the methods that handled the valueChangedListener the effectChangeListener in BaseBean.java

I moved the boolean newUser to the BaseBean for testing, I realize it does
not belong there.

This does not work, shouldn't it?

Just in case Tyler hasn't sorted it out with Akearns yet, or someone else has a similar problem. This one's pretty simple, though some what annoying.

During the JSF lifecycle, ValueChangeListeners happen BEFORE the Values get updated from the model. What is happening is you are updating your value in the listener, then you're change is getting obliterated by the value from the model, which is false.

I had a similar issue where I had a tree with nested checkboxes which I wanted to cascade. Select at the bottom, and all the parents get checked. Deselect at the top, all the children get unchecked.

What I did was re-queue the event by using the following code:

 public void someChangeListener(ValueChangeEvent e) {
    if (e.getPhaseId().equals(PhaseId.UPDATE_MODEL_VALUES)) {
    } else {

This will make doSomeStuff() happen AFTER the UPDATE_MODEL_VALUES phase, which is where the values get pulled from the request.
I'm running into a bit of an issue with the panelToolTip. I'm hoping there's a way around this before I have to go and do semi-major refactoring.

When I put a panelToolTip in my div which is position:absolute; or position:relative;, it goes wonky. I looked it up and found that this is a problem, so I pulled it into its own file which I include without any surrounding panelGroups/divs.

Now, I'm getting an error concerning "findForm" on JSPX compile time. It doesn't do this when I put the tooltips back into the same form (which is currently, within a position:relative div.)

So it seems that the tooltips have to be in the same form as the panelGroup that uses it OR the panelGroup is not in a form. This is, unfortunately, going to make me have to change a lot of markup to get forms in the right spots. Hopefully someone can help me!

Some code...

This breaks.
    <ice:panelGroup panelTooltip="staticTooltip" >
       <ice:outputText value="Hovering on this text will bring a panelTooltip" />
 <ice:panelTooltip id="staticTooltip" style="width: 300px; height: 200px; background: #FFFFFF;">
    <f:facet name="body">
       <ice:outputText value="This panelTooltip is static." />

I'm using the 1.6.2 release with Apache and FireFox.

oleczek wrote:
Not sure if this will help but check



This led me to the right answer. Thanks!

My problem apparently was with the cancel button, which had immediate="true". The UIInput components were maintaining their values after I cancelled, despite me updating the backing bean data, so when they were rerendered, they showed the old values.

Binding to the form and using the recursive UIInput clear method detailed in that post seems to have fixed it.

Thanks again! I feel silly now that I couldn't find that post on my own.
As a preface, I'll note that I've been using IceFaces for about a month now and have found it supremely easy and intuitive, and my co-workers/bosses are all amazed with the quality of our new pages.

That said, I have a very specific and isolated issue. I'm not sure what is so different about this little chunk of code but here goes.

Users can edit and update locations by clicking on an edit button or for new locations, clicking a new location button. This gets sent to an action listener, which updates my backing (session scoped) bean with the appropriate values. The page is then re-rendered and the previously un-rendered section is rendered. When the user is done they either hit submit, to confirm their changes, or cancel, which does nothing. In both cases, the bean is updated and the expression that rendered the edit section is changed back and the edit section disappears.

All this works fine! However, when I try to edit a different location, or create a new one, the values from the previous entry appear in the text input/selectOneMenu fields. The bean is storing the correct value and is seemingly not being updated to these fields. However, some of the properties (a pair of lists which are rendered in data-tables, which I've omitted below) are rendered correctly.

It seems like the HTML is keeping the previous values without updating to the backing bean as I would expect. I'm sure the fields are being re-rendered (or at least, they're not on my screen and then on my screen again later!) I've tried several ways to fix this:

1) Setting the value to a property's properties (value="#{myBean.location.name}")
2) Setting the value to a property and then setting them in the submission function (value="#{myBean.locName}")
3) Binding the elements to the appropriate objects in the bean and directly calling the setValue() method (binding="#{myBean.locNameBind}" ... getLocNameBind().setValue(...) )

None of these seemed to force the system to re-render correctly. They all do exactly what I expect them to do except for not clearing when a new location is prepped for edit.

I'd appreciate any help I can get! Below is the relevant jspx markup and bean code.

The relevant bits of the JSF managed session scope BYOCPMain bean...
 protected _Location location = null; //With appropriate getter/setter
 public void changeLocation(ActionEvent e) {
       _Location newLoc = (_Location) e.getComponent().getAttributes().get("locationToChange");
       if (newLoc == null) {
          newLoc = new _Location();
          newLocation = true;
       } else {
          newLocation = false;
 public String submitLocation() {
       //Update the location data, persist it and update the view
       if (newLocation) {
          //TODO: Add persistance
          availableLocations.add(new LocationWrapper(location));
          newLocation = false;
       location = null;
       return null;
 public String cancelLocation() {
       location = null;
       return null;

The relevant bits of the JSPX.
 <ice:commandLink partialSubmit="true"
                                  <f:attribute name="locationToChange" value="#{loc.loc}"/>
                                  <ice:outputText value="Edit"/>
 <ice:commandButton value="New Location" immediate="true"
                   <ice:panelGroup styleClass="contentBox" rendered="#{BYOCPMain.location != null}">
                         <ice:outputText value="Location: " styleClass="required"/>
                         <ice:inputText id="locationName" required="true" partialSubmit="true"
                         <ice:message for="locationName" styleClass="warnStyle"/>
                      <ice:panelGroup styleClass="optionItem">
                         <ice:panelGrid columns="3">
                            <ice:outputText value="Address: " styleClass="required"/>
                            <ice:inputText id="locationAddress" value="#{BYOCPMain.location.address}" required="true" partialSubmit="true" size="15">
                               <f:validator validatorId="AddressValidator" />
                            <ice:message for="locationAddress" styleClass="warnStyle"/>
                            <ice:outputText value="City: " styleClass="required"/>
                            <ice:inputText id="locationCity" value="#{BYOCPMain.location.city}" required="true" partialSubmit="true" size="15"/>
                            <ice:message for="locationCity" styleClass="warnStyle"/>
                            <ice:outputText value="State/Province: " styleClass="required"/>
                            <ice:selectOneMenu id="locationState" value="#{BYOCPMain.location.state}" partialSubmit="true"  required="true">
                               <f:selectItems value="#{StateList.selectItems}"/>
                            <ice:message for="locationState" styleClass="warnStyle"/>
                            <ice:outputText value="Postal Code: " styleClass="required"/>
                            <ice:inputText id="locationPostal" value="#{BYOCPMain.location.postal}" required="true" partialSubmit="true" size="10">
                               <f:validator validatorId="ZipCodeValidator"/>
                            <ice:message for="locationPostal" styleClass="warnStyle"/>
                            <ice:outputText value="Phone Number: " styleClass="required"/>
                            <ice:inputText id="locationPhone" value="#{BYOCPMain.location.phone}" required="true" partialSubmit="true" size="15">
                               <f:validator validatorId="PhoneNumValidator"/>
                            <ice:message for="locationPhone" styleClass="warnStyle"/>
                            <ice:outputText value="Fax Number: " styleClass="required"/>
                            <ice:inputText id="locationFax" value="#{BYOCPMain.location.fax}" required="true" partialSubmit="true" size="15">
                               <f:validator validatorId="PhoneNumValidator"/>
                            <ice:message for="locationFax" styleClass="warnStyle"/>
                      <ice:panelGroup styleClass="optionItem centered">
                         <ice:panelGrid style="margin:auto;" columnClasses="r,l" columns="2">
                            <ice:commandButton value="Submit" action="#{BYOCPMain.submitLocation}"/>
                            <ice:commandButton value="Cancel" action="#{BYOCPMain.cancelLocation}" immediate="true"/>
Profile for StormTAG -> Messages posted by StormTAG [15]
Go to:   
Powered by JForum 2.1.7ice © JForum Team