Olof Næssén wrote:
Why would you use an f:param tag rather than using
t:updateActionListener?
I didn't know updateActionListener existed. And frankly I don't really
see the difference. Before I used a f:param embedded in a
h:commandLink, now I use a t:updateActionListener embedded in a
h:commandLink but I get the same result. Perhaps I'm missing
something.
t:updateActionListener and f:param are totally different.
t:updateActionListener will update a value in the specified MODEL object
when the associated command is invoked by the user. In other words, it's
properly integrated with JSF.
f:param simply messes about with the http request parameters, leaving
the JSF code to somehow look for the data and deal with it. It's a
servlet-level (not JSF) operation, which makes it useful for generating
URLs that are to be handled by non-JSF code.
Are you somehow then expecting this parameter to continue to exist as
page B is submitted?
Well I somehow thought the "state" of the previous page would be
restored on validation failure. Maybe I should explain what I'm trying
to do. I have an entry which a user can add comments to, much like a
blog entry with user comments. When a user displays the entry a form
for comment submission is present.
To be able to display the entry I pass an entry id. The form I have
has a hidden component with the entry id used when saving the comment,
_but_ when validation fails the entry id is null despite the fact that
I use a hidden component. My guess is that it's set to null because
there is no parameter longer present (in my managed beans section I
set the id property with the parameter, perhaps this is wrong), which
would imply that parameters properties are set after post data
properties.
I think that t:updateActionListener would be perfect for this situation.
Or perhaps t:saveState so that the managed bean that holds info about
the "currently displayed entry" has a lifetime longer than request-scope.
Using the jsf standard session scope to hold the "currently displayed
entry" for the user should also work, but session-scope has a number of
problems; the tomahawk t:saveState approach is generally better.
If you'll forgive me for saying so, it looks like you are trying to
build a JSF application using a struts or plain servlets approach. Try
thinking more like a Swing programmer; JSF is about components, not
about knowing specifically what html parameters are being posted by the
browser. It does take some adjustment...
Regards,
Simon
