[GrooveApp-devel] Re: Another GrooveApp idea for comment

[Marcus B. <mb...@gm...>]

None.

And you probably don't want any...  that would mean maintaining state on th=
e
client and server (and syncing them).  State should be on one or the
other...

On 3/1/06, Allen Lee <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...> wrote:
> > I'll go ahead and add you to the sf.net project.
> >
> > SessionContext is a servlet thing.  (Actually, it's in
> > HttpServletRequest.getSession()).  Related to the 4 levels of context i=
n
> > 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...> 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...> 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?
> > > >
> > >
> >
> >
>