my dog learned polymorphism*
The moose likes JSF and the fly likes Suspicios updates between ICEFace components and Spring Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » JSF
Bookmark "Suspicios updates between ICEFace components and Spring Bean" Watch "Suspicios updates between ICEFace components and Spring Bean" New topic
Author

Suspicios updates between ICEFace components and Spring Bean

Christopher Don
Greenhorn

Joined: Nov 21, 2013
Posts: 4
Hi mooses and moostresses,

I've got some @Component Beans and JSPs linked to it.

Since some time a popup will always show false values in ice:selectBooleanCheckboxes.

I debugged the process and can't find any additional calls from my own code.

I tried to shorten the call stacks to this:




Anyone got a quickshot?

Kind regards,
Christopher
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15959
    
  19

Welcome to the JavaRanch, Christopher!

I'm unclear on the details of what you are asking, but I can tell you this: The number of times that a given JSF backing bean property may be set or retrieved for a given Http Request/Response (JSF lifecycle) process is unpredictable, but can be as many as 5 or 6 times. Which is why property access methods in JSF shouldn't have side-effects or do intensive computing or I/O work.

Incidentally, JSF doesn't use "JSPs". It uses "View Templates". A JSP compiles into an executable servlet class. A View Template compiles into a (non-executable) Component Tree data structure. Actual realization of JSF via JSPs was an early characteristic that was soon dropped. In JSF version 2, you cannot template Views with JSPs at all - only xhtml.

The other observation I will make is that Rule #1 for JSF is that the more JSF-specific code you write, the more likely you are not doing things correctly. So if you are playing around with the JSF internal structures and processes, then you're going to spend a lot of time and obtain relatively little happiness.


Customer surveys are for companies who didn't pay proper attention to begin with.
Christopher Don
Greenhorn

Joined: Nov 21, 2013
Posts: 4
Hello and thanks, Tim.

I'm unclear on the details, too. ;) I'm not very used to frontend development.

The first thing I should correct is that we use jspx not jsp and some quick googeling reveal jspx and xhtml seem to be pretty similar with an advantage in code completion for jspx in eclipse. We also use JSF 2.1.6 and iceFaces 3.3.0.

At the moment I'm not sure about what you mean with "JSF-specific code" and "internal structures and processes". We don't use more than a few elements of the following taglibs:

Maybe the side-effects is a point. We have to tables. MessageTypes and MessageTemplates. If you choose a MessageType a listener will update the MessageTemplates:


With a button we can open a Popup for MessageType details:


This is a shortened Version with one of the checkboxes I'm talking about:


I want happiness. ^^
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15959
    
  19

JSF2, as I said, does not support JSPs. However "xhtml" is merely the conventional file extension for View Templates. If someone wanted to, they could pick "jspx" instead. The actual template would be JSPX in name only, however - it still won't compile down to a real JSP Servlet anymore than an "xhtml" view is technically what the W3C defines as XHTML. In practical use, I wouldn't pick "jspx" as an View Template extension, however, since that would obscure reall JSPXs and thereby remove one of the options available for parts of the webapp that don't need JSF services.

JSF-specific code basically is employing any function or data structure other than those in the javax.faces.model packages. There are times when such stuff is necessary, but in most cases, I stuff those functions over in a utility service class. That way, the majority of the backing beans are mostly POJO and I can more easily test them offline.

Along that vein, there's apparently a lot of very obsolete code out there - plus newer bad code - that over-uses/abuses bindings and listeners. There's almost never a need for an actionListener, for example, The simple action method is POJO and can do almost everything an actionListener normally does.

As far as your actual problem goes, the only thing that makes me suspicious is that you appear to be managing the dialog via backing bean actions. Unless IceFaces is a lot different than RichFaces, most of those functions are client-side (javascript).
Christopher Don
Greenhorn

Joined: Nov 21, 2013
Posts: 4
Given that I was wondering since the beginning for the checkboxes were negated while the second table got updated on selectionListener, which you mantioned it too, I removed it and the process got healed instantly.

Then I put it back in but added an attribute to split the button click and the rowSelector/Listener. It works too and feels better in handling as well.



Thanks for the push to try on that point and your explanation.
 
Consider Paul's rocket mass heater.
 
subject: Suspicios updates between ICEFace components and Spring Bean
 
Similar Threads
Problem with setValue method of an HtmlOutputText object in a JSF backing bean
JSF partial validation
ternary operator
Need to get the current Instance of one backing bean into another
Influence from JavaScript on FacesPortlet-Lifecycle