[Seaside-dev] #decorationClasses preference

[Julian Fitzell]

On Mon, Jul 28, 2008 at 11:45 PM, Paolo Bonzini <bonzini at gnu.org> wrote:
> 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.

As i mentioned in another reply, I can see this being done with
composition but not as a Decoration per se. I think I like this
idea...

> - would it make sense to implement the decoratability on WARequestHandler,
> rather than on sessions?

There is supposed to be a layered system which allows you to use the
lower layers without the upper layers. WARequestHandler is an abstract
class that provides an interface to allow you to write a class that
handles requests. I think that's all it should do.

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

Again, I don't think the lowest layer (request handling) should even
*know* about applications and sessions (session layer) or decorations
(component layer).

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

I wouldn't call #updateUrl: really "duplicated". I mean, it's an empty
method in both places. It's just a hook provided on both class
hierarchies. And request handlers in the general case should not have
persistent state, I think.

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

I'm afraid you've lost me here... why don't decorations need to see
the initial request?

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

Again, lost... how come component doesn't need #renderContentOn: anymore?

You might also be interested in taking a look at the "painter" branch
in the 2.9 repository. I'm playing with refactoring a bit to
compartmentalize the funcitionality of the presenter/component
hierarchy.

>  - #renderWithContext: could be moved to WARenderingContext

How?

>  - what about eliminating #script/#style altogether?

That's another debate. ;) Some people like them for prototyping. I
personally think #style is useful for holding basic structural CSS,
without which the component doesn't work. I would never use it for
actual style, but since you have to know to manually include a library
(and you have to distribute a library for your component), it can be
useful to have the "structural" styling included with your component.
I don't think they do any harm other than leading newbies down the
wrong path, of course...

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

To be honest, I'm not certain I quite get the goal you are striving
for so perhaps I'm just missing your point. But my concern throughout
is the layering and that the inheritance hierarchy make sense from a
logical point of view in terms of functionality, not just from a
protocol sharing point of view. Just because two classes are given to
opportunity to updateRoot:, for example, doesn't mean they need to
share a superclass. Many classes implement #do: as well, but they
don't all need to be Collections.

This brings up something I've been mulling over for the past month.
Our goal with seaside 2.0-2.3 was to really clean up the layering.
Prior to this, people had a really hard time understanding the system
and the hope was that by having a strict layering it would make it
easier. You could understand one layer at a time and clearly see where
the boundaries of functionality were.

I think it really helped (it even helps me keep things straight) and I
feel like those distinctions are getting a little muddied now (error
handlers are using renderers to generate their HTML, for example, but
you should be able to use the request handling layer without the
rendering if you want to). It may be that this is all academic and
that nobody will ever use these layers by themselves and we should
stop worrying about it. But I would still like to see the boundaries
made clear.

So I'm wondering whether it wouldn't make sense to split the
Seaside-Core package into 4:
Seaside-Core-Request
Seaside-Core-Session
Seaside-Core-Component
Seaside-Core-Rendering

These were the 4 main layers as they were designed in 2.3. Maybe the
overhead of managing the packages would make it not worth it but it
would reinforce the distinctions, allow class extensions onto the
lower layers where necessary, and make it easy to run tests on the
lower layers without the higher ones loaded.

Thoughts?