Dan Allen schrieb:
Ken wrote:
So at the surface, it looks like a great way to ensure the user
can't go backwards in the application and redo or undo things they
shouldn't be allowed to do...
Dan wrote:
I didn't really envision this mechanism as a way to prevent the
user
from going backwards. There are much less drastic and more elegant ways
to deal with that problem.
Ken wrote:
however, I don't think it guarantees this without the developer
being really careful. What it DOES do, is allow a sophisticated
developer the ability to cleanup state earlier and make the
application much more efficient in how it uses memory.
Dan wrote:
Yes, that is the idea. It could be a background thread or perhaps a
navigation hook. The developer would have to be aware of the
consequences, but I see it more something a framework will leverage. And
you could serialize access to the tree to ensure it is not invoked
prematurely from a double click (the waiting thread would be able to
react to the tree being absent appropriately).
what about (in addition to offering a remove-method in the api)
integrate component-tree lifecycle with JSR-299 Contexts (conversation
scope) - e.g. automatically clean up views when leaving a multi-page
wizzard?
- Norbert