Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Suspicios updates between ICEFace components and Spring Bean

 
Christopher Don
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18303
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Christopher Don
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 18303
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic