[Seaside-dev] #decorationClasses preference

[Philippe Marschall]

2008/7/29 Julian Fitzell <jfitzell at gmail.com>:
> On Tue, Jul 29, 2008 at 12:38 AM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> 2008/7/28 Paolo Bonzini <bonzini at gnu.org>:
>>> - could WAExpiringHandler also become a WAExpirationDecoration then? This
>>> removes one thing I don't like which is the difference between
>>> handleRequest: and incomingRequest:.  This relationship is more clearly
>>> expressed by containment than by inheritance.
>>>
>>> - would it make sense to implement the decoratability on WARequestHandler,
>>> rather than on sessions?
>>
>> That would pretty much give us JEE servlet filters.
>
> Which would be... good? bad? Are you agreeing or disagreeing with the
> suggestion?

Just an observation.

> I don't quite see how session expiry works as a decoration in the same
> style as component decorations (where the thing being decorated holds
> onto its decorations)

As far as I understood

- get the session
-- if nil create a new one, delegate to next handler
-- if not nil check if it is expired
--- if yes take action (delegate to expired session handler)
--- if not delegate to next handler
- check if too old
-- if yes expire
-- delegate to expired session handler
- everything ok, delegate to next handler

There are some practical problems with this like you need a lot of
information about your environment. Note that even this functionality
could be split up into 3 servlet filters. If you take this approach to
it's extreme you'll end up with a long chain of filters each doing
little work and then delegating to the next one (or doing something
else).

> because the Application needs to call methods on
> the thing it's holding onto to check for expiry and so on.

As far as I understand WAApplication would no longer do that. It would
look the session up which might not exist, be too old or be expired
and then simply delegate.

Cheers
Philippe