ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Anyone? Would be nice to know what developers think about that...?!

In short: I just want to display an ice message with severity WARN, but it does not seem to work.

The snipped of the ICE page looks as follows:

Code:

<ice:form>
    ...
       <ice:panelGroup>
           <ice:inputText id="inputTextFieldId" value="#{mybean.text}" validator="#{myValidator.validate}" onkeyup="iceSubmitPartial(form,this,event);" />
 
           <ice:message for="inputTextFieldId" warnClass="warningText" errorClass="errorText" />
       </ice:panelGroup>
    ...
 </ice:form>

The CSS styles are very simple - bold and italic fonts in warning and error cases, but differed colors (red vs. yellow):

Code:

.errorText {
    font-weight: bold;
    font-style: italic;
    color: red;
 }
 
 .warningText {
    font-weight: bold;
    font-style: italic;
    color: #EEC900;
 }

The validator is also very basic:

Code:

public class MyValidator {
 
    public void validate(FacesContext context, UIComponent component, Object value) throws ValidatorException {
        // A stupid validator that always outputs a warning
        FacesMessage message = new FacesMessage(FacesMessage.SEVERITY_WARN, "Warning Message", "Warning Message Details");
        throw new ValidatorException(message);
    }
 
 }

The code is just very basic for illustration purposes. One might have noticed that the inputText has the onkeyup attribute set to an ICEfaces JavaScript method that triggers a partial submit event. Therefore, on every keystroke, the validator will be triggered.

The good message is: it works - the warning is indeed displayed with the correct message text.

The bad message is: it works not correctly, because the color of the font is red, but not yellow as expected for a warning (according to the CSS styles). Looking at the generated HTML code reveals that the span class is (for some reason) set to errorText instead of warningText:

Code:

<span [b]class="errorText"[/b] ...>Warning Message</span>

Also, if I change the warning to be displayed to e.g. INFO and providing a style class for INFO, the same happens. It seems that only error messages are displayed.

Can someone confirm this bug? If it is indeed a bug, can the ICEfaces team provide a workaround or fix?

Hi Philip,

Your solution with <redirect/> works fine - that is the one we will use in the future.

Thanks a lot!

Given an ICEfaces page which contains a JavaScript tag in the HTML head:

...
<head>
<script language="javascript" src="./js/myscript.js"></script>
</head>
...

Assume that the first page that is loaded contains a command link that refers to the page described above using navigation rules. So when clicking on the command link, the page should be loaded. This is indeed the case, but when looking at the HTML source in the browser, the javascript tag is not shown (which means the script has not been loaded). When reloading the page manually, then the script shows up in the header.

This problem also occurrs when:
a) The script is placed within the body (instead the head)
b) The script is surrounded by <f:verbatim>...</f:verbatim> tags (in either the body or the head)
c) The script is additionally surrounded by CDATA tags like suggested in http://www.icefaces.org/JForum/posts/list/651.page

It seems that ICEfaces does NOT include java scripts on pages that are accessed using a navigation rule.

The only fix that we know is that the javascript inclusion has to be placed on each page (even if the page does not require the java script, which is very uggly).

As a side note: we use a panel border layout on each page... however, ICEfaces MUST allow for inclusion of custom JavaScripts on ANY page.

Can someone confirm this bug? Any suggestions or ideas?

Good point, FlyingElvi, I think it would work with the selectInputText since this component must react immediately on each user input.

No, you are right - the event is triggered if for example the input text field loses focus. But there are situations where you need a validation of the input on each key stroke.

For example, in a wizard, the "next" or "finish" button is dis- or enabled depending on the content of a text field (for example, it might be disabled if the text field is empty). That is why I had to find a workaround.

Would you see another possibility?

I found a workaround that works by setting the onkeyup property:

<ice:inputText value="#{mybean.text}" onkeyup="iceSubmitPartial(form,this,event);" />

The partial submit will ensure that the setText method of mybean is invoked with the entered text.

However, I suggest that the ICEfaces team logs this issue as bug and releases a fix...

Given a button which opens a modal popup window when clicked. The code for the popup window looks like this:

<ice:form>
<ice:panelPopup>
<f:facet name="header">
...
</f:facet>

<f:facet name="body">
<ice:inputText value="#{mybean.text}" valueChangeListener="#{mybean.valueChanged}" />
<ice:outputText value="#{mybean.text}" />
</f:facet>
</ice:panelPopup>

...
</ice:form>

The valueChanged event is not processed at runtime. The same holds if replacing the valueChangeListener by an actionListener. Interestingly, the ICE component's showcase has an example where there is an action listener defined for a command button which - of course works (also for me). In the example above, setting the partialSubmit attribute to true in any of the components does not help.

Is this a bug in ICEfaces and if so, is there a fix or a workaround?

Given a vertical menu and using the default xp style, it seems that it is impossible to disable top-level menu items, e.g.:

<ice:menuBar orientation="vertical" ... >
<ice:menuItem value="Enabled Item" />
<ice:menuItem value="Disabled Item" disabled="true" />
</ice:menuBar>

However, if there are child-menu items, the disabled attribute works properly.

Is this a known issue and is there a workaround to fix it?

ACEGI allows to define which pages can be accessed with a given role, for example based on a path like:

/pages/system/**=ROLE_ADMIN
/pages/monitor/**=ROLE_ANONYMOUS

If an ICEfaces page in the system subfolder is accessed without proper authorization, ACEGI will redirect the request to a access denied page. Of course, this works fine with ICEfaces if the URL is directly entered in the browser.

Now assume that you use ICE's panel border layout where the center area displays the actual content of the page and for example the west area contains a menu. If clicked on a menu item, the content of the body changes.

To avoid reloading the whole page and to reuse code, the body content is contained within ICE's panel stack, for example:

<ice:panelStack ... >
<ice:panelGroup id="body1">
<jsp:directive.include file="/pages/system/mypage.jspx" />
</ice:panelGroup>
<ice:panelGroup id="body2">
<jsp:directive.include file="/pages/monitor/mypage2.jspx" />
</ice:panelGroup>
</ice:panelStack>

Changing the body does not require to enter a URL, but to click on a menu item which selects one of the body IDs. However, ACEGI now is now unable to deny access if necessary.

A workaround is to use ICE's renderedOnUserRole attribute for each panelGroup element - but then, the user is not notified when he is unauthorized because he just gets an empty body.

My two questions are:
a) Is it possible to get ACEGI work with jsp directive includes (probably this question should be posted in an ACEGI forum - but maybe someone knows it)

b) Can I define an alternative body content if renderOnUserRole fails or redirect the call to an access denied page?

Given a table which colors even and odd rows differently using CSS style classes, e.g.:

<ice:dataTable ... rowClasses="evenTableRow, oddTableRow" >

</ice:dataTable>

Now, if adding a (default) row selector like:

<ice:rowSelector />

within a column of the dataTable above, I would expect the rows to be highlighted when the mouse hovers over it (like in the the components showcase example). However, what happens is that only the font color changes while the row color does not.

Removing the rowClasses attribute from the table makes the mouseOverClass effective, showing the behavior of the components showcase example.

Any suggestions? Thanks!