rendering tree2, stale treemodel

[Eric Hsieh <ec...@yahoo.com>]

I'm trying to update data in a treemodel but am
getting stale data.  Debugging it, I've noticed that
after a form is submitted on the page that the tree
resides on, the FacesServlet will restoreView first,
then process any actionListener attached to the form
submit, and finally render the page.

The data that fills my tree (request managed-bean) is
persisted in a database and is refreshed during this
restoreView call.  My actionListener (in this case an
update to the data) is fired next.  Finally the new
page gets rendered. Here's where the problem is.

The line quoted below from HtmlTreeRenderer.java gets
the current value of HtmlTree.  tree.getValue() is the
value that should be rendered.  What does get rendered
is tree, which contains the treemodel from
restoreView().

    public void encodeChildren(FacesContext context,
UIComponent component) throws IOException
    {
        HtmlTree tree = (HtmlTree)component;
        boolean showRootNode = getBoolean(tree,
JSFAttr.SHOW_ROOT_NODE, true);

        if (!component.isRendered()) return;

        if (tree.getValue() == null) return; <-- this
line 160.



Should the value of tree.getValue() get used instead?
Or am I wrong?  I'm currently working around this by
trashing the tree bean to force a refetch.





		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

Re: rendering tree2, stale treemodel

[Sean Schofield <se...@gmail.com>]

> I'm trying to update data in a treemodel but am
> getting stale data.  Debugging it, I've noticed that
> after a form is submitted on the page that the tree
> resides on, the FacesServlet will restoreView first,
> then process any actionListener attached to the form
> submit, and finally render the page.

This is the expected behavior.  It is consistent with the JSF lifecycle.
 
> The data that fills my tree (request managed-bean) is
> persisted in a database and is refreshed during this
> restoreView call.  My actionListener (in this case an
> update to the data) is fired next.  Finally the new
> page gets rendered. Here's where the problem is.

Can you update the backing bean after your action?
 
> The line quoted below from HtmlTreeRenderer.java gets
> the current value of HtmlTree.  tree.getValue() is the
> value that should be rendered.  What does get rendered
> is tree, which contains the treemodel from
> restoreView().
> 
>    public void encodeChildren(FacesContext context,
> UIComponent component) throws IOException
>    {
>        HtmlTree tree = (HtmlTree)component;
>        boolean showRootNode = getBoolean(tree,
> JSFAttr.SHOW_ROOT_NODE, true);
> 
>        if (!component.isRendered()) return;
> 
>        if (tree.getValue() == null) return; <-- this
> line 160.
> 
> Should the value of tree.getValue() get used instead?
> Or am I wrong?  I'm currently working around this by
> trashing the tree bean to force a refetch.

I'm not sure what your are proposing as an alternative.  tree.getValue
*is* what is being used.

I think I understand the nature or your problem, though.  You would
like to update the tree data as a result of an action.  That should be
possibe.  Why not just use the setValue method of the tree?  (Actually
its part of UITreeData but its available to the subclass HtmlTree.) 
Just call this after you are done processing all of the actions (but
before RenderResponse).

Also, there is a struts subproject called Shale.  One of its features
is to add extra steps to the lifecycle.  That could be a good way for
you to handle the refreshing of the data (although in this case I
suspect you could make it work with just JSF.)

sean