[Seaside-dev] #decorationClasses preference

[Lukas Renggli]

>  I'm inclined to drop that preference and add one that adds a tool
>  decoration, since that was presumably the immediate need.

Yes, this is how it used to be in earlier versions of Seaside. I think
we should stick with this, if the new approach with the collection
attribute adds to much complexity.

Some random and unordered thoughts:

- In earlier versions the toolbar was a hardcoded wrapper component,
not a decoration. People wanted to be able to add an remove it on the
fly and add different functionality. The problem of adding new
functionality to the toolbar is solved through the plugin mechanism,
adding and removing the toolbar dynamically is only possible with a
decoration. However, a single preference for the toolbar would not
break this possibility.

- WAAuthenticationDecoration requires a special main class, which
potentially conflicts with other custom main classes. Being able to
add this decoration independent of the main class would be a benefit
in flexibility. However, custom main classes are hardly needed today,
because there are different (and better) hocks to do similar things.

- WASessionProtector is a decoration that does not require
configuration and that is commonly used in deployed scenarios.

- Another thing that is somehow related is the processing of callbacks
within the context of components. Unfortunately this feature
complicates things a lot and makes is nasty to do AJAX. We plan to
drop it. However to support things like WASessionProtector,
WAAuthenticationDecoration and WATransactionDecoration we need a new
extension mechanism

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

Mhh ... I hope this is understandable what I wrote?

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch