|
Try this:
bookList.jsp contains list of books and some
filter fields like author or issuer. After you select an author you will see
only books written by this author. Then you click on a book and go to
bookForm.jsp to edit the book attributes. After you submit changes you will go
back to bookList.jsp, and *previously selected author is steel
selected*.
With this use case, I gave up avoiding
session beans.
Nebojsa
----- Original Message -----
Sent: Sunday, September 25, 2005 7:02
PM
Subject: Re: commandLink not working
inside <t:dataTable>
Thanks Nebojsa & Navid for your reponses,
that help a lot. It makes a lot sense now. What's puzzling me is, this is
a such a common use case, why it's so complicated to make it to work
in JSF. It takes minutes in JSP. I'm now starting another task, ie,
opening a popup in JSF. Another few minutes job in JSP, looks
like another can of worm in JSF. Well, that's for later.
Saul
----- Original Message -----
Sent: Sunday, September 25, 2005 11:30
AM
Subject: Re: commandLink not working
inside <t:dataTable>
You are right.
If you want to use request scope beans, then
you have to restore table model BEFORE action is triggered
(before Apply Request Values
Phase).
If there is attribute var="item" in a
dataTable tag, then you can evaluate #{item} in your action:
FacesContext.getCurrentInstance().getApplication().createValueBinding("#{item}").
JSF implementation have to initialize "item" variable for the row where
you have clicked before it call action method.
If the corresponding item does not exists
then the action will not be called.
There is issue in MyFaces: "This error
condition is not reported". If MyFaces
reported (at least in log) error or warning like "row 3 not exists in table
model", you would be able to track
the problem yourself.
I suggest Saul Qunming Yuan to consider t:saveState, but to save
only minimal values he need to restore a model (like master
primary key), not model itself. t:saveState is like a hidden filed,
but applied earlier.
Also suggest to use session beans sometimes. It
is trickily to develop in JSF only with request beans.
Nebojsa
----- Original Message -----
Sent: Sunday, September 25, 2005 5:25
PM
Subject: Re: commandLink not working
inside <t:dataTable>
CommandLinks are not supposed to work in DataTables with
their beans in pure request scope, AFAIK.
You either have to
*
put the bean in session scope,
* carry around the bean, using
t:saveState,
* set preserveDataModel to true or
* make the getter
to the list you present in the table have direct access to your data
source.
Otherwise, the datatable can't find it's data in the Apply
Request Values Phase and no event is queued.
Can anyone correct me,
if my understanding is wrong, please?
Saul Qunming Yuan wrote:
I have been using the request scope all the time. I don't want to
use session scope.
-----
Original Message -----
Sent:
Sunday, September 25, 2005 9:59 AM
Subject:
Re: commandLink not working inside <t:dataTable>
Did you move your CampusSearchBean from session to
request scope in the transition from 1.0.9 to 1.1.0? This gave me a
lot of headache...
Saul Qunming Yuan wrote:
To answer my own question, after adding the following line
inside <h:form>:
<t:saveState id="CampusSearchBean"
value="#{CampusSearchBean}"/>
The commandLink works again. This is on 1.0.9, I didn't try on
1.1.0. I'm still confused though, I didn't have the above code, but
commandLink worked as well before I started the upgrading
thing.
-----
Original Message -----
Sent:
Saturday, September 24, 2005 10:09 AM
Subject:
commandLink not working inside <t:dataTable>
Hi,
I ran into a strange problem with the commandLink inside
<t:dataTable>. It doesn't go to the method in the backing
bean when the link is clicked. This had been working well a week
ago when my app was on 1.0.9 version. But I run into all kinds of
problems including this one ever since I upgraded to
1.1.0. Now I decided to roll back my app to 1.0.9 version. What's
strange now, not ALL commandLink links work
inside <t:dataTable>, it works in some pages, but it
doesn't in some other pages. This is really frustrating. Any
ideas, folks?
thanks,
Saul
|
