Re: jsf 2.0 datatable reload again and again
Arved Sandstrom wrote:
No matter what framework you use - JSF or Struts or Spring or Wicket -
you're going to have design peculiarities. In some cases you have to do
true workarounds - this isn't one of them. IMHO.
Alexander Burger wrote:
well, thank you for your answer.
I found a way to avoid multiple database calls and get also fresh data for
every request. It is more complicate as the example of BalusC .
I installed in managed bean a new private like:
private String avoid_multiple_call = new String("");
Please follow the Java naming conventions: 'avoidMultipleCall'.
added getter and setter for that.
private boolean avoidMultipleCall;
for me, it is a huge bug in jsf [sic], a very typically problem of a framework.
It's only a "problem" because you label it so.
I can't see any sense, why jsf [sic] should rebuild the same object again and
Then you missed the explanations. Surely you see there is at least a little
sense, based on the repeated explanations. I get that you find it
again during one request. That needs a lot of cpu-time .
Are you cramped for CPU time?
How much more does it need than what you expect?
I don't think, that any programmer can use that multiple calling of getter
method in a positiv way. If I would change the object, build by the getter
In that you are mistaken. Many programmers use JSF in a very positive way,
myself included, not only accepting but relying on that behavior.
But well, it works like a framework works: not very clever.
Actually, it's quite clever indeed, albeit not suited to your requirements.
In fact JSF supplanted frameworks that did not have this feature of multiple
get/set actions, nor a six-layer lifecycle. It was the introduction of those
very details that empowered JSF to be the useful framework that it is.
With great power comes great responsibility. Indeed, the JSF way is
complicated, and definitely requires some study, but only if you wish to
stretch its capabilities to the limit. But understanding even the basics of
how it handles web communications with a true component model, you find that
You seem to have formed your negative opinion of JSF without a very thorough
grounding in it, and your responses seem to bypass posts that gave reasons and
perspectives for the issues you raise. Yes, they are real issues, if
approached from a point of view that requires a different paradigm. In that
frameworks are like frameworks, a tautology that need not be pejorative.
JSF abuse I've encountered runs in a rather different direction, the
custom-tag gewgaws with a Spring dynamic dependency-injection base and a
soup??on of AJAX. Phew! Spaghetti has moved but not vanished.
Once you get the hang of JSF, particularly facelets, if you approach it with
simplicity and rather let the framework handle things for you, the ride gets
I'm not a JSF master yet, but I'm to the comfort zone. I'm an XML /
Oh, and on the table reload thing, you might consider JPA (Java Persistence
API). The inbuilt level-one cache will buy you amelioration without any
special accommodations for JSF's idiosyncracies on your part. Framework or no
framework, though, you always have to accommodate something, and resource
optimization will always be tricky.