[Seaside-dev] #decorationClasses preference

[Paolo Bonzini]

> - 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?

and, would it make sense to have a limited amount of duplication between 
WAComponent and WADecoration, instead of having duplication between 
WAComponent and WASession/WARequestHandler?  I ask that because many 
methods in WAPresenter seem unnecessary in the refactored system:

   - some would be moved up to a new superclass at the top of the
     hierarchy (#application, #isDecoration, #nextPresentersDo:,
     #requestContext, #session)

   - some are already duplicated between sessions and components, such
     as #updateUrl: -- maybe it is possible to move these up too?
     would it make sense to move the #states and callback mechanism
     up to the common class, making the WARequestHandler act as a kind of
     root for #updateUrl:, #updateRoot:, #updateStates: ?

   - some could be moved down to WAComponent (#initialRequest:,
     #processChildCallbacks: which would not be needed by component
     decorations -- the ones that need it would become session
     decorations)

   - some could be moved down to WADecoration (#renderContentOn:)

   - #renderWithContext: could be moved to WARenderingContext

   - what about eliminating #script/#style altogether?

True, there is much handwaving in the above, but at this point you can 
make a class hierarchy like

WAResponseComponent (implements iteration)
   WADecorationChainTop (#decoration/#decoration:/#decorationChainDo: etc)
     WARequestHandler
       WASession
     WAComponent
   WAResponseDecorator
     WADecoration (for components; #handleAnswer:, #renderContentOn: etc)
       WADelegation
     WASessionDecorator
       WASessionExpiration
       WATransactionDecoration
       ...

> Similar to Seaside 2.0 this functionalitycould also be provided by 
> adding these decorations to the session

so why were session decorations later dropped?

Paolo