How can I add cookies to Seaside responses without redirecting?

Question

I'm making a small web application in Seaside. I have a login component, and after the user logs in I want to send along a cookie when the next component renders itself. Is there a way to get at the object handling the response so I can add something to the headers it will output?

I'm trying to avoid using WASession>>redirectWithCookies since it seems pretty kludgey to redirect only because I want to set a cookie.

Is there another way that already exist to add a cookie that will go out on the next response?

Roosevelt

Answer 1

There is currently no built-in way to add cookies during the action/callback phase of request processing. This is most likely a defect and is noted in this issue: http://code.google.com/p/seaside/issues/detail?id=48

This is currently slated to be fixed for Seaside 2.9 but I don't know if it will even be backported to 2.8 or not.

Keep in mind that there is already (by default) a redirection between the action and rendering phases to prevent a Refresh from re-triggering the callbacks, so in the grand scheme of things, one more redirect in this case isn't so bad.

If you still want to dig further, have a look at WARenderContinuation>>handleRequest:. That's where callback processing is triggered and the redirect or rendering phase begun.

Edited to add:

The issue has now been fixed and (in the latest development code) you can now properly add cookies to the current response at any time. Simply access the response object in the current request context and add the cookie. For example, you might do something like:

self requestContext response addCookie: aCookie

This is unlikely to be backported to Seaside 2.8 as it required a fairly major shift in the way responses are handled.

Ratliff

I'm not so worried about the redirections as the flow of control in the code. Thanks, :) – Roosevelt

Answer 2

I've just looked into this in depth, and the answer seems to be no. Specifically, there's no way to get at the response from the WARenderCanvas or anything it can access (it holds onto the WARenderingContext, which holds onto the WAHtmlStreamDocument, which holds onto the response's stream but not the response itself). I think it would be reasonable to give the context access to the current response, precisely to be able to set headers on it, but you asked if there was already a way, so: no.

That said, Seaside does a lot of extra redirecting, and it doesn't seem to have much impact on the user experience, so maybe the thing to do is to stop worrying about it seeming kludgey and go with the flow of the API that's already there :)

Starry

I was trying to figure out how one component could handle the request then render a different component. Having to redirect first then render the other component adds an extra step in the design of the code. Oh well, I'm still learning. Thanks, :) – Roosevelt