Antwort: Re: Re: [tree2] Problems with new TreeModel interface (need help!)

[mathias . werlitz]

[EMAIL PROTECTED] schrieb am 09.08.2005 05:02:57:

> Mathias.  You've got several good ideas here.  I will respond inlinebelow ...
>
> > Well my thoughts:
> >  
> > Supplying a custom TreeModel may make sense, but as we found out it should
> > not cover the
> > expand/collapse state of the component. A sperate state manager seems to be
> > appropriate. But this manager
> > has to be saved with the state of the tree. It would be nice to control this
> > behavior. If the user wants not to save the state (because of a
> > session-scoped model and manager)
> > he could turn off the sate saving of the expand state (kind of
> > isStateManagerTransient()). The model does not need to be saved.
>


> OK so you do see the benefit of a custom TreeModel.  Currently there
> are not a lot of people clamoring for it but back when there was a
> tree vs. tree2 debate this was something that some people thought was
> important.  I think the dynamic tree with SST would be perfect for
> this.  Are you doing dynamic trees in your app now?  If so, how are
> you managing it without a custom tree model?

You are right, I don't use a custom TreeModel right now, I did not felt the need to ;)
But there might be a benefit, I have to think more about it, how it will work in my application.
Yes, I'm displaying dynamic trees, altough they are not that DYNAMIC.
I solved this with my custom tree nodes. The getChildren() method returns a dynamic (updated) list
of the child nodes.


> As for how the manager is saved, why does it have to be saved with the
> state of the tree?  Couldn't this be a session bean?  It wouldn't have
> nearly the memory footprint as storing the entire tree in the session.

No the state of the tree has to be saved (by default) with the tree component - as it was before.
Thats the problem I mentioned in an earlier mail. That would require me to supply a
session-scoped StateManger and is the reason why the tree lost its state.
Consider this example: I supply a request scoped root node or TreeModel. The state of the
tree would be lost on every request. A session-scoped StateManger is not an option for me.

But we could build in a switch, like I explained, that if the user wants to supply a session scoped StateManger and/or
TreeModel he could turn of the saving of the state.

As I understand the code: the state is only a Set of IDs of the expanded nodes. The nodes itself are not saved.
Thus the size is much smaller than the whole tree.

>  
> > One idea maybe to be able to provide the state manager along with the model.
> > This would make it possible to provide
> > a custom state manager - some kind of getStateManager() in the model.
> > Everytime the state manager is restored the model could be updated with
> > state (setStateManager). Than the model may update the state. This method
> > should not be called if the state is transient in the tree.
>
> Interesting idea.  Care to submit a patch for this?

I may try to implement this, but that implies all the changes mentioned before.
Currently my diploma thesis has more priority and I think I found a all-in-one solution
for the JSF redirect problems ... still researching.


>
> I thought about this when I first ran into the problem of the state
> disappearing between requests (before I made the treeBacker in the
> simple examples have session scope.)  But I didn't think it was
> necessary and I was feeling a bit lazy ;-)  Your subsequent post
> convinced me though that this will be a problem.  Lazy probably isn't
> the right word, just busy.  Could you or someone else work up a
> possible patch for this?  People have been promising to help ... now
> would be a good time.

I'm happy I finally convinced you :)

> Well the ID helps to identify the node when processing commands.  For
> instance, in my app we use it to model documents and so the document
> number is the id.  This way when the user clicks on a document to edit
> it, we know which document to display b/c the id is meaningful.

Ok, I see. I used the user object of my tree node for this, because I need some more data there.
 
> I guess I figured that you could always set your node type to whatever
> this default was.  In other words, your tree population code sets the
> deault to "unknown" or "default" and you provide a facet with the
> corresponding name.  So in a way, you can already do this.

Yes. You are right. I didn't used a "default" type and had some problems if the page designer (me ;)
simply forgot a facet.