[shale] Using RemoteCommand with Dialogs

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

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.

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.  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.

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.

TIA,

sean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

[Rahul Akolkar <ra...@gmail.com>]

On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
> > You mentioned the action method in your previous email, I presume you
> > were refering to the DialogNavigationHandler's action method? That
> > would potentially tie behavior specific to this dialog (clearing some
> > backing bean) to the generic dialog processing, which would make that
> > approach far less desirable.
>
> I was referring to the method binding expression in your transition
> that would return the navigation outcome.
<snip/>

OK, I'm back with you now ;-)

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

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

> You mentioned the action method in your previous email, I presume you
> were refering to the DialogNavigationHandler's action method? That
> would potentially tie behavior specific to this dialog (clearing some
> backing bean) to the generic dialog processing, which would make that
> approach far less desirable.

I was referring to the method binding expression in your transition
that would return the navigation outcome.

On my dialogs I usually have a NEXT button that I reuse via Tiles.  It
has an action attribute of "#{someBackingBean.next}".  This gives the
specific dialog a chance to do some final cleanup before transitioning
to the next dialog step.  One example would be to check the user's
submitted value and see if there is already a similar value in the
database.  If there is, the navigation outcome would point to a "Are
you Sure?" type screen?

So I was thinking that you could also dump the ref to the session bean
at this point.  But then I changed my mind.  It seems like
#{dialog.data} is a more logical place.  That is what it was designed
for after all.  As you say, if you go back to the screen it will be
more efficient then recreating the bean all over again.

> -Rahul

sean

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

[Rahul Akolkar <ra...@gmail.com>]

On 11/14/05, Sean Schofield <se...@gmail.com> wrote:
<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.
>
<snap/>

Sounds good, since that is what I believe "data" was designed for,
plus dialog scope is potentially narrower than session scope, and
might fit your needs well, especially if the dialog is re-entrant.


> 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.)
>
<snip/>

You mentioned the action method in your previous email, I presume you
were refering to the DialogNavigationHandler's action method? That
would potentially tie behavior specific to this dialog (clearing some
backing bean) to the generic dialog processing, which would make that
approach far less desirable.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

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

[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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

["Frank W. Zammetti" <fz...@omnytex.com>]

Craig McClanahan wrote:
> Since URL rewriting is a server side thing, you'd want to make sure you 
> did the rewriting as you rendered the JavaScript code that will compute 
> the URL to which the asynch request should be sent.

Yeah, that's probably true... I was confusing myself thinking a browser 
did it normally when cookies are turned off, but of course that's not 
true, it's just part of the URL you submit to (assuming it was rewritten 
server-side, like you said).  Still, I half wonder if XMLHttpRequest 
might be smart enough to do it behind the scenes... something to test 
anyway, although I suspect your right.

> Craig

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

[Craig McClanahan <cr...@apache.org>]

On 11/14/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > Reminds me of something I haven't actually verified ... does the session
> > cookie get sent in by an XmlHttpRequest?
>
> Yes, it does. All cookies from the originating domain are sent
> automatically, including the session cookie, just like any other HTTP
> request.


Cool.

I'm not sure what happens if cookies are disabled though... will it be
> smart enough to do URL rewriting too? I would assume so, but I'm not sure.


Since URL rewriting is a server side thing, you'd want to make sure you did
the rewriting as you rendered the JavaScript code that will compute the URL
to which the asynch request should be sent.

Craig

Re: [shale] Using RemoteCommand with Dialogs

["Frank W. Zammetti" <fz...@omnytex.com>]

Craig McClanahan wrote:
> Reminds me of something I haven't actually verified ... does the session
> cookie get sent in by an XmlHttpRequest? 

Yes, it does.  All cookies from the originating domain are sent 
automatically, including the session cookie, just like any other HTTP 
request.

I'm not sure what happens if cookies are disabled though... will it be 
smart enough to do URL rewriting too?  I would assume so, but I'm not sure.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: [shale] Using RemoteCommand with Dialogs

[Craig McClanahan <cr...@apache.org>]

On 11/14/05, Sean Schofield <se...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>