[Seaside] SqP - Design question

[Brian Brown]

On Dec 17, 2003, at 2:20 AM, Cees de Groot wrote:

> On Wed, 2003-12-17 at 09:58, Julian Fitzell wrote:
>> BUT, I am basically on holidays now, so I am more than happy to pull 
>> up
>> the SBlogLite code and have a look at it, or to have a look at your
>> stuff, Cees - I certainly have a pretty good idea what is considered
>> "Good Seaside Design".  I'm off to bed now but if you want to send me
>> anything to look at or chat on email or IRC or something tomorrow, let
>> me know.
>>
> The major issue is the overall 'componentizing'. If you look at SqP
> (easy when you're duplicating a running website ;-)), you have a top
> that is relatively static (I'm planning to keep it a fixed element in
> the new site), then two columns with various components: an article
> overview, some text boxes, and two lists (most recent diary entries and
> most recent accounts).
>
> The major question at the moment is how to do the flow control (it's 
> the
> hardest bit about Seaside, I think mostly because there's so much to
> unlearn). I can see there's an outer frame (with the top navbar), which
> holds some configuration of subcomponents. The problem I'm having is
> that some of the links have non-local effects - if you click on a diary
> entry, everything below the navbar gets replaced with one single new
> component. I'm mostly wondering how you can/should do that without too
> much coupling between the components...
>

Ah yes, fun, fun, fun :-)

The way I usually structure mine is by having a ControlCenter or 
MainApp (or insert some name here) component that handles the 
arrangement of subcomponents. For example, a Navbar would be 
instantiated by this ControlCenter, as would components for the main 
content and the Sidebars.

When a component is created, I pass in the ControlCenter.  In your 
above Diary example, I assume you are doing something like: Diary call: 
OtherComponent, but the Diary component is the only one currently 
active, so the call: replaces everything on the page. If you use an 
"ubrella" like component whose renderContentOn: just lays our your 
style sheet framework and uses ivars to track components corresponding 
the functional areas of the page, then you can replace just the one bit 
of functionality in the page by using the call: answer: semantics.

If you want to replace the whole page, then from any component you can 
do ControlCenter call: (OtherComponent new).  You can successively use 
call: as many times as you want, and as each component sends answer: 
then the delegate chain unwinds.

So what I'm (not very well, I'm sure) trying to say is that the key is 
breaking up the page into components controlled by an "Umbrella" and 
figuring out which components to send call: to for the desired results.

Also, on the Navbar, judicious use of clearDelegate can return your app 
to it's beginning state.

And if everything I've said here is obvious to you, just ignore me ;)

Brian


>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside