One reason why commandLink doesn't work in dataTable

Question

Ok, so I think I've got an explanation why commandLink doesn't work in dataTable when the model bean is request scoped. Maybe somebody can tell me if I'm wrong.
I have a model bean that generates table rows based on some input criteria (request parameters).
So, we validate the inputs, apply them to the bean and render the page. Once the inputs have been applied to the bean, a request for table rows returns rows, no problem.
However, we put a commandLink in each row, so we can expand the details. Maybe we even get smart and repeat the input row-generating criteria as a hidden field in the page.
Unfortunately, when the user hits the commandLink, the list page simply refreshes, maybe even w/out table rows. The user doesn't get the details page as expected.
Why not?
Because: in the DECODE phase (even before validation and before "immediate" values have had their valueChangeListeners called), we ask the model bean for the table rows, so we can decode the commandLinks. Unfortunately, in "decode" phase, the request-scoped model bean has not had its row-generating criteria updated (that happens in the "update model" normally, or at the END of the decode phase if we got cute by (1) setting the "immediate" attribute on the row-generating criteria to "true" AND (2) set a valueChangeListener to allow us to update the model bean early. The END of the decode phase isn't good enough -- in the middle of that phase, when we're attempting to deocde commandLinks, the model bean has no citeria, so there's no row data. No row data means no iteration over commandLinks to decode them and queue ActionEvents. So, we march through the rest of the phases, process no events, and return to the screen of origin (the list screen) with no errors.
So, what's the solution?
One solution is to make the model bean session-scoped. Fine, maybe we can store a tiny bit of data in it (the search criteria), so it's not such a memory drag to have it live in the session forever. How do we get that data in? A managed property in faces-config.xml with value #{param.PARENT_KEY} won't work because it's assigning request-scoped data to a session-scoped holder. JBoss balks, and rightly so. Do we write code in the model bean that pulls the request parameter out of thin air? (FacesContext.getExternalContext()....) I don't really like to code the name of a specific http request parameter into the bean, I think it's the job of the JSP or faces-config.xml to achieve that binding (request parameter to model propery). Plus, I'd be sad to introduce a dependency on Faces in what was previously just a bean.
Is there a better way?
In my particular situation, we're grafting some Faces pages onto an already-existing non-Faces application. I don't get the luxury of presenting the user an input field and binding it to a bean. All I've got to work with is a request parameter.
Hmm, I guess I just answered my own question. if all I've got to work with is a request parameter, some ugliness is inevitable, I guess.
I guess the best fix is to cheat and have the bean constructor look for a request parameter. If it finds it, it initializes the criteria field (which, in my case, is the key of an object that has a bunch of associated objects (the rows data), but could be more-general d/b search criteria).
(I looked at the "repeater" example code in the RI, but it basically statically-generates its data and then uses 100% Faces (of course) to manage the paging (where "page number" is essentially the "criteria").
Comments? Did I miss something obvious?
John.

Answer 1

...or I could just break down and do the thing I was hoping to avoid (outputLink instead of commandLink):
<h:outputLink value="/faces/Detail.jsp">
  <f:param name="PARENT_KEY" value="#{bean.parentKey}"/>
  <h:outputText value="#{bean.label}"/>
</h:outputLink>It's still a "hardcoded" parameter name, but at least the binding is in the JSP and faces-config.xml, not the bean Java code.