ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

You may have to think about your own cache strategy then. The behavior that you recognized is ok from the presentation point of view. But, if you have data intialization behind this you get into trouble.

Try something like

Code:

if (mydata = null) {
    mydata = initialize;
 }
 
 return mydata;

I can't remember exactly if immediate="true" in combination with partial submit can help here. You may try this, first.

Else you have to think about your own validation. Maybe you do it the classic way an start it when a submit button is hit. ICEfusion / ICEcube has an example for such a class. However the details are described in the book.

Maybe you should rethink your form design. Do you really need such a number of autocomplete fields?

You should think about a single form and may use partial submits to process certain parts of the form.

The use of composite components is limited in the number of instances on a single page, exactly one - if you want to keep them simple in structure and reusability. I also recommend to use a backing bean for each composite component, as we do with each page.

You may have a look at the ICEfusion stuff for more code examples (see footer).

Maybe its the use of uppercase:

Code:

#{WrapSpecEditor.wrap.benchmark}

I would expect this if your bean reference is "wrapSpecEditor":

Code:

#{wrapSpecEditor.wrap.benchmark}

Today my free and native iPhone app for ICEfaces developers became available in iTunes:

Details

For a general architecture using "Flex components" as a client technology inside an ICEfaces presentation we have used a Spring-BlazeDS bridge into our backend:

http://blog.rainer.eschen.name/2008/07/02/flex-supports-spring-are-you-ready-to-skip-web-20/

The Flex components are used for more complex presentations which need more interactivity. Such components communicate directly with the Spring backend (so there's no dependency to the JSF backing beans) and can integrate all Flex libs you can "buy". This allows to reuse them in AIR contexts, too.

Some example code to have a look at?

Do you have changed any extentson definition in the faces-config? Any example code?

I'm collecting ideas for the second ICEfaces book.

Before I started the first book I asked the community to suggest topics. A lot of those topics were advanced topics. The first book was a beginners book. So, I had to skip the most of those suggested topics.

Now, with the success of the first book, I'm able to suggest an outline for those advanced topics. I re-read the thread for the first book and I already have some ideas. But, most of the mentioned topics are almost one year old.

So, I think it's time for another poll:

After reading the first book. What kind of information do you expect from a second ICEfaces book?

What are you talking about in the first post: cpu usage, of course.

Have you tried a simple

Code:

<f:view>

BTW: It hasn't to be outside the html tag.

Any ideas how the design of your application can create such a behavior?