[GrooveApp-devel] Re: Another GrooveApp idea for comment
Status: Alpha
Brought to you by:
mbreese
From: Robert W. G. <rwg...@ro...> - 2006-03-02 05:44:09
|
thanks guys, your comments helped me get a good picture of the whole thing....and, i think it would be a good idea, as it would have a specific place for ajax related data to live...making the framework more ajax friendly from the get go....it might be just a holder object, but thats all it has to be Blobert Marcus Breese wrote: > Yep... It would basically be a place to put objects that isn't quite > a request and isn't quite a session object. > > So, it basically doesn't do too much... that or, it is more like > continuations :) > > On 3/2/06, *Allen Lee* <ano...@gm... > <mailto:ano...@gm...>> wrote: > > So the only difference between this and the SessionContainer is to > help the programmer disambiguate between ajax requested data and > normal browser-interaction-requested data on the server side? > > On 3/2/06, Marcus Breese < mb...@gm... > <mailto:mb...@gm...>> wrote: > > Almost... > > > > You'll have to explictly send data to the client, not setting it > in the > > AjaxRequestContext. Why? Because the client won't have access > to it. > > You'll have to send the client the deltas/status/whatever for > whatever > > operation you requested. > > > > So, lets just say you're running a pizza website. > > > > /order/new -> creates a new pizza object, stores it in > AjaxRequestContext. > > > > to add pepperoni: ajax call to /order/add/pepperoni -> server > takes the > > stored pizza object and calls > pizza.addTopping(Toppings.Pepperoni). It then > > returns "OK" to the client. > > > > The client then does the appropriate drawing... > > > > Or, you could do another ajax call to retrieve the correct > picture (img > > src="/order/pizza/current") > > /order/pizza/current 302 redirects to /images/pizza/pepperoni.png > > This can also be done with GrooveApp... :) > > > > > > On 3/2/06, Allen Lee < ano...@gm... > <mailto:ano...@gm...>> wrote: > > > Ok, I think I finally understand. You want to store temporary > > > ajax-only data on the server side in a custom Context object > (similar > > > to the SessionContext). This way you make your ajax call, > throbbage > > > happens on the client side, thinking happens on the server > side and > > > eventually when the server has some data to report it sets it > on the > > > AjaxRequestContext and tells the client "Done.". Is that close? > > > > > > On 3/1/06, Marcus Breese < mb...@gm... > <mailto:mb...@gm...>> wrote: > > > > None. > > > > > > > > And you probably don't want any... that would mean > maintaining state on > > the > > > > client and server (and syncing them). State should be on > one or the > > > > other... > > > > > > > > > > > > On 3/1/06, Allen Lee <ano...@gm... > <mailto:ano...@gm...>> wrote: > > > > > Ok, that makes sense. How much knowledge is there between > the JS > > > > > XmlHttpRequest and the SessionContext? None at > all? Some? Not > > > > > enough? > > > > > > > > > > > > > > > > > > > > > > > > > On 3/1/06, Marcus Breese < mb...@gm... > <mailto:mb...@gm...>> wrote: > > > > > > I'll go ahead and add you to the sf.net <http://sf.net> > project. > > > > > > > > > > > > SessionContext is a servlet thing. (Actually, it's in > > > > > > HttpServletRequest.getSession ()). Related to the 4 > levels of > > context > > > > in > > > > > > Servlets/JSP : Application/Servlet, Session, Request, Page. > > > > > > > > > > > > I'm proposing to add a GrooveManaged context in between > the Session > > and > > > > > > Request. > > > > > > > > > > > > So, what you'd do for an Ajax call is place an object in an > > accessible > > > > > > context. Then you'd make async calls with the > ajaxrequest object > > (mine) > > > > to > > > > > > a url that is handled by GrooveApp. > > > > > > > > > > > > Right now, a GrooveApp "action" (method) must return a > > > > > > com.grooveapp.controller.Result object. This Result > object is built > > > > using > > > > > > staticly accessed methods. Right now, you can return a > few things: > > JSP > > > > > > (handled by a request dispatcher), XML, HTML, Text, > JavaScript, or > > Null. > > > > > > (The null result assumes that you are outputing > something manually > > via > > > > the > > > > > > response object). So, it is very easy to have ajax only > server side > > > > > > actions... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 3/1/06, Allen Lee < ano...@gm... > <mailto:ano...@gm...>> wrote: > > > > > > > I think I'm missing some pieces here. The > SessionContext is a JS > > > > > > > object? As I learn more about how WebWork is > implementing its > > ajax > > > > > > > theme I might have more to say about transferring data > > ajax-style.. > > > > > > > > > > > > > > One thing that feels dirty about doing ajax with the > struts right > > now > > > > > > > is being shoehorned into the idea that you are > returning some > > > > > > > ActionMapping defining where you go next even if the > action is > > being > > > > > > > invoked as a result of an ajax call that doesn't care > about > > > > > > > ActionMappings. How hard do you think it would be to > have > > ajax-only > > > > > > > server side actions? As it stands now you can hit any > URL that > > the > > > > > > > ajax action would hit and receive weird behavior with > url-munging. > > > > > > > > > > > > > > Talking out of my butt, > > > > > > > Allen > > > > > > > > > > > > > > Oh yeah - I noticed the grooveapp-devel list thing, > want to add me > > as > > > > > > > a developer to grooveapp sometime after you get the > svn repo set > > up > > > > > > > there as well? My sf account is 'alllee'. > > > > > > > > > > > > > > On 3/1/06, Marcus Breese <mb...@gm... > <mailto:mb...@gm...>> wrote: > > > > > > > > So, here's another silly idea that I'd like to throw > out (in > > case > > > > > > > > you're interested). > > > > > > > > > > > > > > > > So, it might behoove a new Java framework to work > out of the box > > > > with > > > > > > > > Ajax. Well, as you guys now have seen, there really > isn't a > > good > > > > way > > > > > > > > to get data from the server to the client for Ajax > calls in Java > > w/o > > > > > > > > using the SessionContext. > > > > > > > > > > > > > > > > Well, since in GrooveApp, the framework controls the > requests, > > > > perhaps > > > > > > > > it would be a good idea to include an > Ajax{Request}Context (or > > > > > > > > GrooveRequestContext). This way, the dev could put > an object of > > > > > > > > interest in that context, and asynchronously call > methods to > > update > > > > > > > > that object. It wouldn't be too hard to do, as > you'd just have > > to > > > > > > > > create a new context (if needed), give it an id, and > populate > > it. > > > > > > > > Then with the next request, you could scan the > parameter list > > for > > > > > > > > AJAX_CONTEXT_ID (or something like that), and load the > > appropriate > > > > > > > > context. The ajax call from the client would just > have to > > include > > > > > > > > AJAX_CONTEXT_ID in as a parameter in it's call. > > > > > > > > > > > > > > > > The Ajax{request}Contexts could be stored as a map > in the > > > > > > > > SessionContext. When a new request comes in, the last > > AjaxContext > > > > > > > > could be cleared (or set to timeout in 2 minutes, or > something). > > > > > > > > > > > > > > > > Ideas? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |