path appendix to initial url once more

Hi,

I know now why the appendix to my URLs are missing.
Lukas advised to try something like this:

initialRequest: aRequest
   super initialRequest: aRequest.
   self session redirect

But the redirect is the one which removes the appendix
from the URL. actionUrlForKey: in WASession resolves
to WAEntryPoint>>baseUrl.

As long as there isn't any redirect it works quite
good. In my case it is the check for cookies which does
the redirect. Removing the check makes it work.

So for me there are two options how to solve the problem:

- there is an appropriate way of checking cookies without
  redirecting. But I fear this has to be a javascript one
  instead, right?

- I'm not too familiar with how seaside works exactly. The
  WASession>>actionUrlForKey: is the method which is called
  in both ways (cookie check and session redirect). Would it
  be feasible to take the appendix there from the current-
  Request and append it to url?

thanks in advance,

Norbert

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/2/27, Norbert Hartl <[hidden email]>:
Right, but even in this case you would have to know before the initial
request whether cookies are supported. You could build a proxy that
does this before the initial request hits the Seaside application. Or
a static html page that would contain JavaScript and "forward to
Seaside".

And finally an other option would be to add the cookie as well as the
_s parameter to the very first response. As soon as we have a session
cookie we can drop the _s parameter. Seaside does currently not
support this as this depends on the J2EE refactoring.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Wed, 2008-02-27 at 21:38 +0100, Philippe Marschall wrote: Thanks, I'll have to think about the proxy. Otherwise it isn't too
problematic to deliver a script with the first request. In a load
balanced scenario only the second request is questionable? :)

> And finally an other option would be to add the cookie as well as the
> _s parameter to the very first response. As soon as we have a session
> cookie we can drop the _s parameter. Seaside does currently not
> support this as this depends on the J2EE refactoring.
>
What is "J2EE refactoring"?
 
Norbert

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/2/28, Norbert Hartl <[hidden email]>:
The J2EE refactoring aka the WAContext refactoring:

This is about the architecture of Seaside, users (you) should not be
affected by this. It's main idea is to make life for us as developers
(Lukas, Michel, me, ...) and the vendors (Cincom, Gemstone,
Instantiations) and "vendor-like" people like Magma easier. Don't
worry it hasn't really anything to do with J2EE besides that I got the
idea from there.

The justification of this refactoring are two architectural problems
Seaside currently has:

First despite all the flaming against "brain-dead" J2EE (actually
called JEE these days) what Cincom needs for their Glorp and locale
stuff needs is [1] and what Gemstone for their transparent persistence
needs is [2]. Sure there are work arounds, but they're work arounds.

Second, often we are in the position where we need a certain piece of
information that is store in a different place "far away" from where
we are. The J2EE soultion to this is contexts and stuff that is scoped
in these contexts. We already have such a mechansim in place for the
current session. But is very specific to the session. Sometimes we
need the rendering context, sometimes we need the current response,
sometimes we need to now if the server adapter is in "encoding" mode.
Thiss has lead to an overuse of WASession for stuff that doesn't
really belong there like the current application or the current
request. The idea is to generalize the current approch and provide
contexts for the current rendering context, request, session,
application, dispatcher, server adapter (...) that are nested within
each other. Additionally we want to provide the ability to add
listeners when such contexts are created or destroyed and the ability
to store stuff in such contexts.

This mail is about how much of this is already implemented ;-)

[1] http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/javax/servlet/http/HttpSessionListener.html
[2] http://java.sun.com/products/servlet/2.5/docs/servlet-2_5-mr2/javax/servlet/ServletRequestListener.html

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside