4

My code here iterates the columns for each row and the rendered attribute is calculated every iteration, overcalling testRule.

<p:dataTable ...>
    <p:column ...>
        ...
    </p:column>

    <p:column rendered="#{managedBean.testRule('rules.canDoActions')}">
        <!-- Action buttons -->
        <h:commandButton ...>
        <h:commandButton ...>
    </p:column>
</p:dataTable>

To get better performance, I was wondering to set the result into a variable, but I don't know how... It would become something like this:

   <?:??? var="canDoActions" value="#{managedBean.testRule('rules.canDoActions')}">
   <p:dataTable ...>
        <p:column ...>
            ...
        </p:column>

        <p:column rendered="#{canDoActions}">
            <!-- Action buttons -->
            <h:commandButton ...>
            <h:commandButton ...>
        </p:column>
    </p:dataTable>

Also, I'm not allowed to use Core Tag Library, wich means that <c:set ../> is out of question.

In that scope, how could I set a variable? Or, if not possible, what do you suggest to solve the performance?

falsarella
  • 12,217
  • 9
  • 69
  • 115
  • 1
    Why aren't you "allowed" to use JSTL core taglib? – BalusC Dec 20 '11 at 18:57
  • @BalusC: Architect decided not to use JSTL with JSF because (if I am not wrong) it runs in a different phase of other tags, and people here were using it recklessly, mixing things and a lot of bugs and confusions appeared (if I am not wrong, JSTL core isn't rerunned on ajax calls). JSTL was created for JSP and it was logically designed for it. I know it can be used with JSF, but, here, the architect decided that the JSTL use wouldn't be a best practice. Despite the fact that we sacrificated JSTL, our problems were resolved (believe, JSTL isn't all that necessary). Glad to talk to you, @BalusC! – falsarella Dec 20 '11 at 19:21
  • 4
    JSTL is indeed not necessarily necessary. But it may be helpful when you want to build the view dynamically. See also http://stackoverflow.com/questions/3342984/jstl-in-jsf2-facelets-makes-sense While your architect has definitely a valid point (it's indeed often confusing to starters), but completely restricting it is a bit overzealous. Well, `` would be the answer to your question. If that isn't an option (or reveals other problems; it doesn't go well together with view scoped beans, for example), then you've got to cache itself in the getter. See Jigar's answer. – BalusC Dec 20 '11 at 19:29
  • I agree with BalusC, in addition do note that the JSTL that is used with Facelets is not the *real* JSTL that ships with JSP. It's a specifically adapted 'emulation'. Notice that not even all attributes and tags are present. Then, the native Facelets lib also has both build-times and run-time tags. – Mike Braun Dec 21 '11 at 09:33
  • Also, if I'm not mistaken both c:set and ui:param don't actually store a result, but are just a dynamic alias to the expression assigned to it. Maybe using immediate syntax ${...} will get you that effect. – Mike Braun Dec 21 '11 at 09:40

1 Answers1

6

I'm not allowed to use Core Tag Library, wich means that <c:set ../> is out of question

Then you can have it stored on Bean itself and check if it is null calculateRules and set value or simply return.

For Example:

HashMap<String, Boolean> map;

public boolean testRule(String stringInput) {
   Boolean result = map.get(stringInput);

   if (result == null) {
       //calculate and set in map
   }

   return result;
}
falsarella
  • 12,217
  • 9
  • 69
  • 115
jmj
  • 237,923
  • 42
  • 401
  • 438