Mike Wright wrote:
> Hi Ken,
>
> I have a JBI "show" page that is reached via table or tree
> hyperlinks of the form:
>
> /jbi/showBindingOrEngine.jsf&name=foo&type=binding-component#show
>
> I need to refresh this page after a table on it has an action
> performed (dropDown "operation" selection or "delete" button click),
> so I added to the dropDown and Button/Link's "<!command..." handlers
> the following final command (in a sharedTable.jsf file):
>
> navigate(page="#{sessionScope.navigateOperationRefresh}")
>
> where the variable is set (by several including JBI "show" pages) to
> the URL with the appropriate request parameters (and an anchor id of
> #show). Unfortunately, the request parameters and anchor id seem to
> be discarded. The correct .jsf page is displayed, but the fields that
> depend upon the request parameters are empty (and the property sheet
> section of the page with the 'show' anchor is not scrolled-to, so the
> user sees the page "jump to the top").
>
>
> Could you add code to the navigate method to extract the request
> parameters (and anchor id) and use them when creating the view? (Or
> tell us how to? Maybe Priti can help you do this?)
I won't be able to get to the changes immediately (I'm @ AjaxWorld right
now). However, you may have some success w/ the redirect handler which
works differently.
Also, I'm not sure there is much I can do in this case b/c the request
parameter map is immutable and the browser doesn't utilize the '#"
character on a server-side forward.
> If not, can you suggest an alternative approach? I'm about to
> commit my changes with a workaround of refreshing to a list view, but
> that's kind of disconcerting to have the show screen you are looking
> at "go away" because you performed some operation on the table (but it
> is better, for now, than to "jump to the top" of a page with missing
> fields).
Let me know if redirect doesn't work... it requires an extra request and
may cause other problems (depending on what you're depending on --
request attributes set on the previous request will be gone).
> BTW, we'll also need this "refresh-a-page-with-request-params"
> capability when we add a cluster/stand-alone instance targets table
> with its own refresh-needed-after operations.
Another approach would be to make the page you're navigating to able to
operate w/o request parameters (i.e. request attributes). This would
provide other ways for you to get the info you need to the page.
Good luck!
Ken
> Regards,
> Mike
> ---
>
>