[Seaside-dev] #decorationClasses preference

[Philippe Marschall]

2008/7/28 Paolo Bonzini <bonzini at gnu.org>:
>
>> - There was the recent discussion of dropping the feature that
>> callbacks are processed within the context of the component that
>> rendered it. This complicates things a lot and is especially nasty
>> when doing AJAX stuff. However, the fact that callbacks are processed
>> within the defining components is a requirement for decorations like
>> WATransactionDecoration, WASessionProtector,
>> WAAuthenticationDecoration. Similar to Seaside 2.0 this functionality
>> could also be provided by adding these decorations to the session. I
>> guess that would make sense, because Cincom for example did some
>> experimental session decorations. The only thing from stopping me
>> doing this refactoring was the fact that it would duplicate a lot of
>> functionality from WAComponent to WASession, but it potentially could
>> also simplify the session (for example cookie sessions could be a
>> decoration) which is a huge mess right now.
>
> I think I agree a lot.
>
> Random bag of thoughts:
>
> - 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.

Cheers
Philippe