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.
Joined: Nov 21, 2013
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:
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.
Joined: Nov 21, 2013
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.
subject: Suspicios updates between ICEFace components and Spring Bean