[Seaside-dev] #decorationClasses preference
Paolo Bonzini
bonzini at gnu.org
Tue Jul 29 05:07:32 UTC 2008
>> - 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
More information about the seaside-dev
mailing list