[Seaside-dev] #decorationClasses preference

[Julian Fitzell]

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?

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) because the Application needs to call methods on
the thing it's holding onto to check for expiry and so on.

I can imagine a WAExpiringHander being initialized with a session
object, though. This might well be a simpler arrangment than we have
currently and does nicely remove one of the arbitrarily named
*Request: methods. :)

Julian