grooveapp-devel Mailing List for GrooveApp
Status: Alpha
Brought to you by:
mbreese
Menu
▾
▴
grooveapp-devel — GrooveApp developers list
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
(22) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Allen L. <ano...@gm...> - 2006-04-18 05:00:50
|
Hey Marcus, sorry for the late response, been busy getting settled into
Tempe. So if I understand what you want to do here correctly, you want to
be able to specify/configure what kinds of http requests you'll respond to?
If so, why wouldn't a simple @Path(name=3D"/signin", requestType=3D
HttpRequestType.GET) and then the method wouldn't be invoked for anything
other than a http GET request for any URLs matching "/signin"?
Of course I may have misunderstood what you're trying to do?
Is there email commit notification going on yet? Want to set that up with =
a
separate grooveapp-svn list?
On 3/31/06, Marcus Breese <mb...@gm...> wrote:
>
> I just spent 2 hours adding a feature to GrooveApp...
>
> then decided that I didn't like it... so I took it all out.
>
> What was the feature? URL Request mapping via Http method
> (GET,POST,PUT,DELETE). I rewrote a good chunk of the url mapping code to
> make this work... I never got it perfect, and then I realized that I was
> increasing the memory requirements for url mapping at least 2-fold. And =
the
> code was very sloppy, as there isn't a good way to do with w/o starting t=
o
> make custom data structures... (or prepend the HTTP method to the path:
> GET$/signin^, and that just looks silly, and you have to add a GET and a
> POST for most everything).
>
> I ended up just making the call in the method like so:
> @Path("/signin")
> public Result signin(Request req) {
> if (req.getRequest().getMethod().equals("GET")) {
> return signinRedirect(req);
> }
>
>
> This ultimately ends up being simpler... and I thought you might
> appreciate the silliness of it all.
>
|
|
From: Marcus B. <mb...@gm...> - 2006-03-31 07:04:38
|
I just spent 2 hours adding a feature to GrooveApp...
then decided that I didn't like it... so I took it all out.
What was the feature? URL Request mapping via Http method
(GET,POST,PUT,DELETE). I rewrote a good chunk of the url mapping code to
make this work... I never got it perfect, and then I realized that I was
increasing the memory requirements for url mapping at least 2-fold. And th=
e
code was very sloppy, as there isn't a good way to do with w/o starting to
make custom data structures... (or prepend the HTTP method to the path:
GET$/signin^, and that just looks silly, and you have to add a GET and a
POST for most everything).
I ended up just making the call in the method like so:
@Path("/signin")
public Result signin(Request req) {
if (req.getRequest().getMethod().equals("GET")) {
return signinRedirect(req);
}
This ultimately ends up being simpler... and I thought you might appreciate
the silliness of it all.
|
|
From: Allen L. <ano...@gm...> - 2006-03-07 03:02:33
|
Looks good, sorry I haven't had a chance to comment yet, I'm sick with that
throat virus that you gave to me last week, finally succumbed to it on
Saturday night and trying to finish up some work on the gabel project. I'l=
l
have more input soon as soon as this nyquil fog lifts.
On 3/6/06, Marcus Breese <mb...@gm...> wrote:
>
> I thought I'd let you guys know the further progress on the Path
> Mapping...
>
> So, last night I worked on adding RegEx path matching. I just finished
> migrating all matching to RegEx mapping in the backend. The normal
> configuration (default class/method name or @Path("/foo") annotations) st=
ill
> work, but they are converted at initialization to RegExs.
>
> Since Java doesn't do named groups in regexs, I didn't add the support fo=
r
> named parameters, but I did add a "String[] getPathParameters()" to the
> Request object to support retrieving matched groups.
>
> Ex:
> @Path("^/(\\d\\d\\d\\d)/(\\d\\d)/(\\d\\d)/$")
>
> will match /2006/03/06/
> and getPathParameters() will return String[] { "2006", "03", "06" }
>
>
> Marcus
>
|
|
From: Marcus B. <mb...@gm...> - 2006-03-07 02:56:30
|
I thought I'd let you guys know the further progress on the Path Mapping...
So, last night I worked on adding RegEx path matching. I just finished
migrating all matching to RegEx mapping in the backend. The normal
configuration (default class/method name or @Path("/foo") annotations) stil=
l
work, but they are converted at initialization to RegExs.
Since Java doesn't do named groups in regexs, I didn't add the support for
named parameters, but I did add a "String[] getPathParameters()" to the
Request object to support retrieving matched groups.
Ex:
@Path("^/(\\d\\d\\d\\d)/(\\d\\d)/(\\d\\d)/$")
will match /2006/03/06/
and getPathParameters() will return String[] { "2006", "03", "06" }
Marcus
|
|
From: Marcus B. <mb...@gm...> - 2006-03-06 08:01:24
|
Added ability to have regex path matching.
Kept all other matching as is for the moment.
if an @Path() annotation starts with "^" it is considered a regular
expression.
All regular expression mappings are absolute.
This also allows for regex matching of groups. This will be passed to the
function as a String[].
(This can also be represented by a vararg to allow for reuse of methods).
Note: java regex's need
to be '\' escaped twice.
Ex:
@Path("^/(\\d\\d\\d\\d)/$")
public Result listByYear(Request req, String...params) {
String year=3Dnull;
if (params.length=3D=3D1) { year=3Dparams[0]; }
}
The necessitated adding a second possible signature for methods: (Request,
String[]), but the orignal
is still supported.
The original mapping patterns are still used as well.
The order of url matching is this:
1) regex
2) full (controller/action) path
3) default action / controller index (/controller/)
4) default controller / app index (/action/)
5) default action/controller (/)
2-5 may be deprecated in favor of migrating all path matching (internally)
to use regex's.
Also, I decided to avoid using named matches (\P{year}\d\d\d\d) because Jav=
a
regex/Pattern doesn't support this out of the box and would require another
pre-processing step, as well as a new signature for (Request,Map)
Comments? Ideas? Issues?
Marcus
|
|
From: Marcus B. <mb...@gm...> - 2006-03-06 01:16:09
|
Mailing lists are working... :) On 3/4/06, Allen Lee <ano...@gm...> wrote: > > What I can remember from talking to him last was a simple directed > graph where you choose a starting node and an ending node and there is > at most one or two directed paths from the start to end, passing > through multiple other nodes (which are sites of interest like towns, > post offices, scenic areas, mountains, rivers, etc.). Each node of > interest has a constellation of metadata annotating it so we can track > overall elevation change between each node/leg of the journey, > distance between nodes, estimate the time it would take to travel by > foot between nodes given some default or user-specified velocity, and > so on. > > Oh, also, I just read this page earlier regarding how the django > framework deals with url dispatching, thought it might be useful on > the list as well - maybe you've seen this already? > > http://www.djangoproject.com/documentation/url_dispatch/ > > > On 3/3/06, Marcus Breese <mb...@gm...> wrote: > > How would it be calculated? > > > > Is it something like this: Set defined trails. Set defined waypoints > along > > said trails. Set attributes for each leg of the trail. Set other > > interesting things along trail like sights, resupply info, etc... ? > > > > Something like that? I'm just trying to understand the basic algorithm= . > > > > > > On 3/3/06, Allen Lee <ano...@gm... > wrote: > > > So there's this application that I was thinking about writing for my > > > friend for part of his http://www.trailfaqs.com website that's aiming > > > to be a useful informational resource for hikers - he wants a hike > > > planner that will let him select a startpoint, endpoint, and give him > > > more information about the area in between those two points like how > > > far resupply towns are spaced about, the overall elevation change, > > > etc. > > > > > > Anyways, the thing was, I was planning on writing this as an exercise > > > to learn RoR, but maybe it'd be useful as a testbed application for > > > exercising grooveapp as well. There's no compensation really, other > > > than providing an application that other people will probably find > > > useful. There's really nothing out there that does this kind of thin= g > > > for people wanting to hike the appalachian trail or the pacific crest > > > trail seriously (i.e., for months). > > > > > > Allen > > > > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > > reply-to changed. > > > > > > > > > > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642 > _______________________________________________ > GrooveApp-devel mailing list > Gro...@li... > https://lists.sourceforge.net/lists/listinfo/grooveapp-devel > |
|
From: Allen L. <ano...@gm...> - 2006-03-05 04:06:11
|
What I can remember from talking to him last was a simple directed graph where you choose a starting node and an ending node and there is at most one or two directed paths from the start to end, passing through multiple other nodes (which are sites of interest like towns, post offices, scenic areas, mountains, rivers, etc.). Each node of interest has a constellation of metadata annotating it so we can track overall elevation change between each node/leg of the journey, distance between nodes, estimate the time it would take to travel by foot between nodes given some default or user-specified velocity, and so on. Oh, also, I just read this page earlier regarding how the django framework deals with url dispatching, thought it might be useful on the list as well - maybe you've seen this already? http://www.djangoproject.com/documentation/url_dispatch/ On 3/3/06, Marcus Breese <mb...@gm...> wrote: > How would it be calculated? > > Is it something like this: Set defined trails. Set defined waypoints alo= ng > said trails. Set attributes for each leg of the trail. Set other > interesting things along trail like sights, resupply info, etc... ? > > Something like that? I'm just trying to understand the basic algorithm. > > > On 3/3/06, Allen Lee <ano...@gm... > wrote: > > So there's this application that I was thinking about writing for my > > friend for part of his http://www.trailfaqs.com website that's aiming > > to be a useful informational resource for hikers - he wants a hike > > planner that will let him select a startpoint, endpoint, and give him > > more information about the area in between those two points like how > > far resupply towns are spaced about, the overall elevation change, > > etc. > > > > Anyways, the thing was, I was planning on writing this as an exercise > > to learn RoR, but maybe it'd be useful as a testbed application for > > exercising grooveapp as well. There's no compensation really, other > > than providing an application that other people will probably find > > useful. There's really nothing out there that does this kind of thing > > for people wanting to hike the appalachian trail or the pacific crest > > trail seriously (i.e., for months). > > > > Allen > > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > reply-to changed. > > > > > > > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > > > > > > > > > > > > > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-03 05:43:21
|
How would it be calculated? Is it something like this: Set defined trails. Set defined waypoints along said trails. Set attributes for each leg of the trail. Set other interesting things along trail like sights, resupply info, etc... ? Something like that? I'm just trying to understand the basic algorithm. On 3/3/06, Allen Lee <ano...@gm...> wrote: > > So there's this application that I was thinking about writing for my > friend for part of his http://www.trailfaqs.com website that's aiming > to be a useful informational resource for hikers - he wants a hike > planner that will let him select a startpoint, endpoint, and give him > more information about the area in between those two points like how > far resupply towns are spaced about, the overall elevation change, > etc. > > Anyways, the thing was, I was planning on writing this as an exercise > to learn RoR, but maybe it'd be useful as a testbed application for > exercising grooveapp as well. There's no compensation really, other > than providing an application that other people will probably find > useful. There's really nothing out there that does this kind of thing > for people wanting to hike the appalachian trail or the pacific crest > trail seriously (i.e., for months). > > Allen > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > reply-to changed. > > > > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > > > > > > > > > > > > |
|
From: Allen L. <ano...@gm...> - 2006-03-03 05:25:35
|
So there's this application that I was thinking about writing for my friend for part of his http://www.trailfaqs.com website that's aiming to be a useful informational resource for hikers - he wants a hike planner that will let him select a startpoint, endpoint, and give him more information about the area in between those two points like how far resupply towns are spaced about, the overall elevation change, etc. Anyways, the thing was, I was planning on writing this as an exercise to learn RoR, but maybe it'd be useful as a testbed application for exercising grooveapp as well. There's no compensation really, other than providing an application that other people will probably find useful. There's really nothing out there that does this kind of thing for people wanting to hike the appalachian trail or the pacific crest trail seriously (i.e., for months). Allen On 3/2/06, Marcus Breese <mb...@gm...> wrote: > reply-to changed. > > > On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 06:26:01
|
I thought I'd let you two know, I moved the SVN repository tonight... You can now get to it at: https://svn.sourceforge.net/svnroot/grooveapp I thought I'd go ahead and try out SF.net's SVN support... Bob, if you'd like commit access, create a SF.net user account, and I'll ad= d you to the list. On 3/2/06, Robert W. George <rwg...@ro...> wrote: > > 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=3D"/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 th= e > > > 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 las= t > > > AjaxContext > > > > > > > > > could be cleared (or set to timeout in 2 minutes, or > > something). > > > > > > > > > > > > > > > > > > Ideas? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 05:41:23
|
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...> 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...> 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=3D"/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...> 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...> 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 th= e > > > > 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 > > > > 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...> wrote: > > > > > > > I think I'm missing some pieces here. The SessionContext is = a > JS > > > > > > > object? As I learn more about how WebWork is implementing it= s > > 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 i= s > > 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 (i= n > > case > > > > > > > > you're interested). > > > > > > > > > > > > > > > > So, it might behoove a new Java framework to work out of th= e > 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 t= o > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 05:39:40
|
reply-to changed. On 3/2/06, Marcus Breese <mb...@gm...> wrote: > > > |
|
From: Allen L. <ano...@gm...> - 2006-03-02 05:31:40
|
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...> 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 t= hen > 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=3D"/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...> 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...> 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...> 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 > > > in > > > > > Servlets/JSP : Application/Servlet, Session, Request, Page. > > > > > > > > > > I'm proposing to add a GrooveManaged context in between the Sessi= on > 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 bu= ilt > > > using > > > > > staticly accessed methods. Right now, you can return a few thing= s: > JSP > > > > > (handled by a request dispatcher), XML, HTML, Text, JavaScript, o= r > Null. > > > > > (The null result assumes that you are outputing something manuall= y > via > > > the > > > > > response object). So, it is very easy to have ajax only server s= ide > > > > > 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 rig= ht > 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-mungi= ng. > > > > > > > > > > > > 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 se= t > 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 J= ava > 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 (o= r > > > > > > > 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 ha= ve > 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 somethin= g). > > > > > > > > > > > > > > Ideas? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 05:26:50
|
|
From: Marcus B. <mb...@gm...> - 2006-03-02 05:24:24
|
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 the= n 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=3D"/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...> 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...> wrote: > > None. > > > > And you probably don't want any... that would mean maintaining state o= n > the > > 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 > > 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 buil= t > > 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 sid= e > > > > 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 m= e > 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 bo= x > > 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 Jav= a > 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 o= f > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
From: Allen L. <ano...@gm...> - 2006-03-02 05:07:48
|
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...> 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...> 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 contex= t > in > > > Servlets/JSP : Application/Servlet, Session, Request, Page. > > > > > > I'm proposing to add a GrooveManaged context in between the Session a= nd > > > Request. > > > > > > So, what you'd do for an Ajax call is place an object in an accessibl= e > > > context. Then you'd make async calls with the ajaxrequest object (mi= ne) > 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: J= SP > > > (handled by a request dispatcher), XML, HTML, Text, JavaScript, or Nu= ll. > > > (The null result assumes that you are outputing something manually vi= a > 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 n= ow > > > > is being shoehorned into the idea that you are returning some > > > > ActionMapping defining where you go next even if the action is bein= g > > > > 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-onl= y > > > > 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 upda= te > > > > > that object. It wouldn't be too hard to do, as you'd just have t= o > > > > > 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 appropriat= e > > > > > context. The ajax call from the client would just have to includ= e > > > > > 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 AjaxContex= t > > > > > could be cleared (or set to timeout in 2 minutes, or something). > > > > > > > > > > Ideas? > > > > > > > > > > > > > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 04:55:16
|
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? > > > > > > > > > > > > |
|
From: Allen L. <ano...@gm...> - 2006-03-02 04:53:42
|
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 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 usin= g > 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 th= e > 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, perhap= s > > > 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? > > > > > > > |
|
From: Marcus B. <mb...@gm...> - 2006-03-02 04:13:26
|
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 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...> 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? > > > |
|
From: Allen L. <ano...@gm...> - 2006-03-02 04:01:36
|
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?
>
|
|
From: Robert W. G. <rwg...@ro...> - 2006-03-02 03:18:04
|
thats a really good idea, and along the lines of what I was asking about
today...i wanted to know the best way to use ajax with grooveapp, and
this sounds like the way to go :)
Marcus Breese 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?
>
|
|
From: Marcus B. <mb...@gm...> - 2006-03-01 23:10:20
|
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.=20
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?
|
|
From: Marcus B. <mb...@gm...> - 2006-01-02 23:58:07
|
I thought I'd let you know I refactored a bunch of stuff today. Mostly in the Services... First, I renamed the GrooveService interface to Service (this matches "Controller"). I also added some stuff to the groove-config.xml (see http://grooveapp.com/groove-config.xml) for services... mainly the ability to define a ServiceFactory to build a service. I have one implemented (SpringManagedServiceFactory -> see http://grooveapp.com/Spring-managed_service).<http://grooveapp.com/Spring-m= anaged_service%29.>.. I haven't gotten a chance to test this, but it should work... it's pretty simple. It pulls a Service from a spring application context. The refactoring in Services should be source code compatible... most change= s are picked up the BaseHibernateService. The skeleton app was updated to reflect these changes. I also made some updates to the build.xml to be a little smarter. For Controllers, I changed the annotations for them. There is no requirement for @MappedController anymore (redundant). To take up the slac= k from @MappedController, I added an @DefaultAction annotation. All of this has been documented on the Wiki. Let me know if this breaks anything you're working on, or if you think I'm on crack... Marcus |