On 11/14/05, Sean Schofield <[EMAIL PROTECTED]> wrote:
>
> I was hoping for some feedback on this design approach ..
>
> I have a dialog with several different screens. One of the screens is
> using inputSuggestAjax (a MyFaces - Tomahawk component.) The list of
> choices that backs this input component is quite large (approx 8,000
> choices.) I was hoping to combine the RemoteCommand stuff in Shale
> with this component and to do so with the best possible performance.
That's the kind of use case the remoting support was designed for :-).
My idea is to have a bean, FooBacker, that has a method
> getSelectItems() that returns an array of SelectItems[]. This bean
> would have session scope.
Reminds me of something I haven't actually verified ... does the session
cookie get sent in by an XmlHttpRequest? If not, you'll need to include it
(or modify the path) so that the correct session id is available to the
server.
The idea is that the initial list of
> choices for the component would be the complete, unfiltered list of
> items, from this method. Then each keystroke narrows the list down.
> Each keystroke would post to a command that extends BasicSelectItems.
> We'll call this command ReviseFooList.
>
> The legal() method in ReviseFooList uses FacesContext to evaluate
> #{fooBacker.selectItems} in order to return the array of total
> possible choices. The match() method then limits this list based on
> the "test" String that has been passed via parameter. Finally, just
> before the dialog transition (in the action method), I would set the
> #{fooBacker} reference to null.
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?
Does this sound right? What about my idea of caching the bean with
> the total list in session scope and then getting rid of it when we
> transition out of the view state? This seems to be a safe way to
> reuse the list but its not as restrictive as application scope. I
> don't want to use application scope because the list may be updated by
> the same or different user(s) at any point in time.
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.
TIA,
>
> sean
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
