[snip]
> I take it this is to avoid keeping the list around when you don't need it (
> i.e. you're not on the view containing the Ajax component)? I presumeit must
> be relatively cheap to populate the overall list in the first place?
Yes that is the point. Its cheap enugh to create it for each dialog
but not so cheap as for each keystroke. Unfortunately it has to be
recreated b/c other users may be adding their own values to the list
of possible values.
The only other possibility I thought of was application scope and to
invalidate that bean when a new value is added. Besides being a
little complicated, I think you could run into threading issues. What
if another request already has a reference to this bean as you are
setting it to null?
[snip]
> Session scope makes sense (versus request), obviously, because the
> individual asynchronous requests will all be different. Whether it makes
> more sense than application scope is pretty much requirements dependent, but
> in genera makes sense only if the list is actually different for different
> users.
I also thought maybe dialog scope would be the way to go here. I
could bind to the inputSuggestAjax choices to
"#{dialog.data.selectItems}. If I turned FooBacker into a
ViewController I could make sure that the selectItems value was
populated.
This way it sticks around for the life of the dialog. So if you go
back to the dialog step where the list is needed you don't have to
repopulate it from scratch. (My earlier idea was to dump as you
transition to the next state.)
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
