[Seaside-dev] #decorationClasses preference

[Paolo Bonzini]

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

It's just that the examples using that would become session decorations 
according to Lukas's email.

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

Yes, but it can provide hooks to decorate a handler with another one (a 
"servlet filter").

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

You're right -- in fact I'd probably like what is now an accessor on the 
current request context to become a class-side method of WARequestContext.

>>  - some could be moved down to WADecoration (#renderContentOn:)
> 
> Again, lost... how come component doesn't need #renderContentOn: anymore?

The implementation of #renderContentOn: in WAPresenter is only used by 
decorations.  Components are supposed to override it.

>>  - #renderWithContext: could be moved to WARenderingContext
> 
> How?

Just "swap" receiver and argument.  The law of demeter is not violated 
more or less if you do that.  Like

WARenderingContext>>renderContentOf: aPresenter
     | html callbacks |
     callbacks := self callbacksFor: aPresenter.
     html := aPresenter rendererClass context: self callbacks: callbacks.
     (aPresenter showHalo and: [self isDebugMode])
         ifTrue: [(WAHalo for: aPresenter) renderContentOn: html]
         ifFalse: [aPresenter renderContentOn: html].
     html flush

Every statement there seems to use *both* the context and the presenter. :-)

> That's another debate. ;) Some people like them for prototyping.

You can use #updateRoot: too, I am not saying that file libraries should 
be the only way.

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

As I said, I was not sure that my hierarchy actually made sense.  I have 
no historic perspective as I started using Seaside at 2.6.

OTOH if all classes implementing #do: were Iterables (not Collections) 
they would all share #inject:into: too, which might be a good thing. :-)

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

As I am working with a file based system, I am always in favor of more 
componentized systems.  Even if they do not result in actually separated 
packages, they result in easier to manage source code files. 
Seaside-Core.st is now 17,000 lines which is not big, the problem is 
that it is only one file.

Paolo