RSF Discussions Forum

I have a question about a producer that is a Navigation Case Reporter and a couple backing beans that process user actions from the view rendered by that producer. The producer is here:
https://source.sakaiproject.org/contrib/textbook/tbook/trunk/tool/src/java/org/sakaiproject/tbook/tool/producers/UBookBooksProducer.java
Let's look at the links for renewing book offers that appear in this view. The backing bean is here:
https://source.sakaiproject.org/contrib/textbook/tbook/trunk/tool/src/java/org/sakaiproject/tbook/tool/RenewBookOfferBean.java
When a user clicks on a link to renew a book offer, it invokes the RenewBookOfferBean.processActionRenew() method. If the renewal succeeds, that method returns a string "renewBookOfferBean.renewed", and if it fails the return value is "renewBookOfferBean.not_renewed". Both navigation cases are included in the list returned by UBookBooksProducer.reportNavigationCases(), and they both attempt to navigate back to the view produced by the UBookBooksProducer. There's a third navigation case for deleting offers that navigates to the delete-confirm view instead. So far so good.

The problem is that it is not working as I would expect. I put some breakpoints in eclipse and try it out. Every time I run it, UBookBooksProducer.fillComponents() executes before RenewBookOfferBean.processActionRenew(). The result is that the renewals are actually occuring, but they are not reflected in the view that is produced. So the user clicks the "renew" link for a book offer and gets back a page showing the book is still not renewed. That's the way it's working in production and on our test servers. This is confusing for users.

Any idea why this is happening or what I can do to fix it? One approach would be to process the renewal in the producer's fillComponents() method instead of the backing bean, but that seems nonsensical.

Thanks. Jim

There's a JIRA ticket for the problem in the textbook tool in sakai:
http://bugs.sakaiproject.org/jira/browse/TXB-170

Well - it depends what you mean by "before" - there are 3 complete request cycles here -

i) render - fillComponents for UBBP creates the UICommand and view
ii) action - the processActionRenew is serviced on the coming POST cycle, which then redirects to
iii) render - fillComponents again for UBBP would show the state updated.

Given that fillComponents will never even execute on the same HTTP request cycle as processActionRenew, you should never see these executing in an "unexpected" order. I am at a bit of a loss to guess what might be happening here, but it would be productive to look at the sequence at the HTTP level - if you open up the views in Firebug, do you see the client redirect occuring as you expect? Is there perhaps some unusual item on the page which is generating an extra request to the server?

Some general observations, although you didn't ask for them

i) navigation back to the current view is actually the default, so you can leave out the two renewed NavigationCases
ii) You only need report the correct type of ViewParameters, so you can just return new SortViewParameters() from getViewParameters
iii) For the renew-item-id, it is not necessary to fabricate your own hidden inputs in the markup directly - RSF will do it for you, if you just add a UIELBinding to the overall UIForm or UICommand.
iv) for "comments:" it isn't necessary to go to all the trouble of making a UIBranchContainer. If you really want two tags when it is shown, and none without, you can just issue the plain UIVerbatim on the server, apply rsf:id="comment" on the <div> and an rsf:id="payload-component" on the <span>.

Hopefully we can make some progress with your real issue though

That helps. The link has an onclick handler to submit the form *AND* an href attribute that links back to the same page. Hmmm.