[Seaside] path appendix to initial url once more

[Philippe Marschall]

2008/2/28, Norbert Hartl <norbert at hartl.name>:
> On Wed, 2008-02-27 at 21:38 +0100, Philippe Marschall wrote:
>  > 2008/2/27, Norbert Hartl <norbert at hartl.name>:
>  > > 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?
>  >
>  > 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".
>  >
>
> 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"?

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