seam s:link fetchs list multiple times. big error !

[bulloncito]

s:link fetchs list multiple times, here's what happens, this is .xhtml fragment:

<h:dataTable id="users" value="#{selectEmployee.resultList}" var="employee">
 <h:column> ... simple columns: employee.name, employee.phone, etc ... </h:column>
 <h:column>
 <s:link propagation="none" view="/register/register-employee.xhtml" >
 <f:param name="employeeId" value="#{employee.id}" />
 </s:link>
 <s:link propagation="none" view="/register/edit-calendar.xhtml" >
 <f:param name="employeeId" value="#{employee.id}" />
 </s:link>
 // some other links
 </h:column>
</h:dataTable>

... and the Bean code looks like this:

(I'm not extending EntityQuery because I needed lots of custom filters, for wich EntityQuery was not smart enough, like multiple EL bindings, or no binding at all, but thats a different matter)

public List<Employee> getResultList() {
 // some initialization
 log.debug("fetchin' page from " + pageBegin + " to " + pageEnd ) ;
 return listEmployees.subList( pageBegin , pageEnd ) ;
}

... the thing is, in logs, there is a print of debug when list is being fetched, then, lets say, if list has n results, and my page has m links per row, then there are n*m links, well, there are n*m fetchs. That sucks. If I change s:link for a href="something.seam?myParams" everything works fine, that however would be a bad anti-pattern sad sorry solution. I'm guessing the most common thing in the world would be to use links per row, so having multiple fetchs would be a bug/error/something-bad ...

I'm using SEAM 1.2.1GA, jBoss-4.2.0.GA, ajax4jsf1.1.1Snapshot, richfaces-3.0.1-SNAPSHOT, jdk1.6.0_02

Any ideas what is going on? Should this be posted as a bug on jira? Should I sit down and cry like a baby?

[gavin.king]

You need to show much more code than that.

[bulloncito]

Didn't wanted to bloat the post, but it happens with every dataTable I have, wheter they use query objects, my own custom beans, or even bean.property of type list, they all get queryed again for every s:link in every row (of a h:dataTable).

Here's a quick sample, the COMPLETE page list-regions.xhtml:

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
 xmlns:c="http://java.sun.com/jstl/core"
 xmlns:ui="http://java.sun.com/jsf/facelets"
 xmlns:h="http://java.sun.com/jsf/html"
 xmlns:f="http://java.sun.com/jsf/core"
 xmlns:s="http://jboss.com/products/seam/taglib"
 xmlns:a="https://ajax4jsf.dev.java.net/ajax"
 template="/template.xhtml">

<!-- content -->
<ui:define name="content">

<div class="section">
 <span class="errors">
 <h:messages globalOnly="true"/>
 </span>
 <h1>#{messages.list_regions_label}</h1>
</div>

 <div class="section">
 <h:dataTable id="regions" value="#{regions.resultList}" var="region" rowClasses="row0,row1" >
 <h:column rendered="#{s:hasRole('Debug')}">
 <f:facet name="header">id</f:facet>
 #{region.id}
 </h:column>
 <h:column>
 <f:facet name="header">#{messages.region_name_label}</f:facet>
 #{region.name}
 </h:column>
 <h:column>
 <f:facet name="header">#{messages.region_options_label}</f:facet>

 <s:link propagation="none" view="/register/register-region.xhtml" style="text-decoration: none">
 <h:graphicImage url="/img/status_bullet/pencil_blue.gif" onmouseover="return escape('#{messages.region_edit_label}');" styleClass="icon" />
 <f:param name="selectedRegionId" value="#{region.id}" />
 </s:link>

 <s:link propagation="join" view="/list/list-employees.xhtml" >
 <h:graphicImage url="/img/status_bullet/avatars_blue.gif" onmouseover="return escape('#{messages.view_region_employees}');" styleClass="icon" />
 <f:param name="selectedRegionId" value="#{region.id}" />
 </s:link>

 <s:link propagation="join" view="/list/list-complexes.xhtml" >
 <h:graphicImage url="/img/status_bullet/house_blue.gif" onmouseover="return escape('#{messages.view_region_complexes}');" styleClass="icon" />
 <f:param name="selectedRegionId" value="#{region.id}" />
 </s:link>

 </h:column>
 </h:dataTable>
 </div>

</ui:define>

<!-- sidebar -->
<ui:define name="sidebar">
 <ui:include src="/menu-simple.xhtml" />
</ui:define>

</ui:composition>

and the actual full entityQuery that does the work (it is the COMPLETE source, that's all):

@Name("regions")
public class RegionList extends EntityQuery {

 @Logger Log log ;

 @Override
 public String getEjbql() {
 return "SELECT r FROM Region AS r WHERE r.active > 0 ORDER BY r.name " ;
 }

 @Override
 public List getResultList() {
 log.debug("fetchin' list") ;
 return super.getResultList() ;
 }
}

there are 16 entries on the database, it prints in the logs:

DEBUG [RegionList] fetchin' list
X 49

exactly 49 times, one for the table, one for each s:link (16*3+1), if I remove 1, 2, or the 3 s:links, then it prints 33 (16*2+1), 17 (16+1) and 1 (1 :P) times respectively. So, it's fetching again for each s:link on the table.

... this HAS to be an error.

[bulloncito]

... guess what? just found out: Even an empty <s:link /> will make extra fetchs :(

[pmuir]

Yes, this is the way JSF works. It doesn't cache the result of a valuebinding. This is why @Factory style pattern is useful (or of course EntityQuery as it caches the query result until the query is dirtied).

[bulloncito]

It doesn't cache the result of a valuebinding.

.. then why

<h:dataTable id="regions" value="#{regions.resultList}" var="region">
 <h:column rendered="#{s:hasRole('Debug')}">
 <f:facet name="header">id</f:facet>
 #{region.id}
 </h:column>
 <h:column>
 <f:facet name="header">#{messages.region_name_label}</f:facet>
 #{region.name}
 </h:column>
</h:dataTable>

... does not make extra fetchs, even thou it uses region var, and

<h:dataTable id="regions" value="#{regions.resultList}" var="region">
 <h:column>
 <s:link />
 </h:column>
</h:dataTable>

... does them ?

If only s:link makes those extra fetchs, I don't believe that is default behavior.

[pmuir]

I can't replicate with Seam2.

[bulloncito]

Tried to migrate once with no success ( currently jBoss 4.0.5.GA + SEAM 1.2.1.GA) ... will try again and report status ;)

[bulloncito]

Don't sure it's the latest, or the proper document:

http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jboss/jboss-seam/seam2migration.txt?revision=1.2&view=markup&sortby=date

... but:

Before you get started with Seam2, you'll need to make a few changes to
your existing code and configuration. This process should not be too
painful

... is so untrue, it is painful :_(

I'll stay a bit longer with seam 1.2.1 and its flaws :P

[bulloncito]

Done, it was painful, updated to Seam2, and error is identical ; ) Entity Query is fetched multiple times for the very same case, if I use even empty <s:link /> tags, List is fetched multiple times, for entityQuery objects that check for dirtied parameters, this could no be so noticeable as an undesired performance problem, but I insist: This SHOULD NOT be default behavior. And it does happen.

[pmuir]

Please submit a testcase to JIRA, like I said I couldn't replicate this.

[fhh]

I can guess what happens: <s:link /> is trying to find out the datamodel selection and is acessing the list behing the value of its UIData parent.

I would say this behaviour is expected. Something similiar should happen if the poster uses <h:commandLink /> instead of the ... hack.

Regards

Felix

[pmuir]

Felix, yes, good point. Perhaps we can work around it. Anyway I can't even replicate so...

[bulloncito]

Tried it. Won't work. Changed <s:link /> for h:command as follows:

<h:form>
 <h:commandLink value="#{region.name}" >
 <f:param value="#{region.id}" name="regionID" />
 </h:commandLink>
</h:form>

... witch now need forms (or links are disabled with an ugly warning in seam2) for tiny navigation links. That, by the way, does not fail, however should not be the solution.

Please be patient, I'm creating the tiniest complete case for the jira, wich I'm still learning how to post, so I'm reading a lot ; )

[fhh]

TBH I don't see the problem at all. What is so bad if the getter of your list is called multiple times. As you have already written it is not a performance issue.

Regards

Felix