[Seaside] What's the difference and why??

[Brian Brown]

On Feb 27, 2006, at 2:51 PM, Rick Flower wrote:

> Brian Brown wrote:
>> Hi Rick - let's step back for a sec and talk about a different  
>> structure....
> Yea.. I was hoping someone might give me an idea of a better way to  
> proceed!  Thanks!

No problem :)

>> What *I* do, and others may have different patterns for their  
>> seaside apps, is to create a main page component, and #call: (this  
>> is Smalltalk notation for denoting a message send, or a method  
>> call in C++ parlance) the components that I want to show up on the  
>> page. So, as a simple example, you might have an initialize method:
>>
>> initialize
>>     mainPage := MainPage new.
>>     aboutPage := AboutPage new.
>>     enrollPage := EnrollPage new.
>>     contactPage := ContactPage new.
>>     menuArea := MenuArea on: self.
>>
>> mainPage, aboutPage etc. are instance variables on your main App  
>> class - say MyWebApp, where the initialize is located.
> That makes sense and I was thinking about doing something like that  
> so I wouldn't need to instantiate new instances of each
> class on the fly..

Yeah, you don't want to instantiate a new component class for every  
render. You normally get one per session.

>> Then, in MyWebApp>>renderContentOn:
>>
>> renderContentOn: html
>>     html divClass: 'sidebar' with: [html render: menuArea].
>>     html divClass: 'contentarea' with: [html render: mainPage].
> Excellent!
>> Then in MenuArea class, you would have a class side method like:
>>
>> on: aComponent
>>     ^ (self new) parent: aComponent
> Ahh.. When might I ask does this get invoked?  Is this part of  
> object instantiation when the above
> "html render: menuArea" gets rendered?

This get's called from that initialize method above, so you have an  
instance of the MenuArea class sitting in the menuArea ivar (short  
for instance variable). The html render: menuArea doesn't instantiate  
a new version of the class, it simply sends the current html renderer  
to the renderContentOn: method of the MenuArea class.

Does that make sense?


>
>> renderContentOn: html
>>     html unorderedList: [
>>            html listItem: [html anchorWithAction: [self parent  
>> clearAllDelegates] text: 'Home'.].
>>            html listItem: [html anchorWithAction: [self parent  
>> mainPage call: self parent aboutPage] text: 'About'.].
>>           html listItem: [html anchorWithAction: [self mainPage  
>> call: self parent call enrollPage] text: 'Enroll'.].
>>            html listItem: [html anchorWithAction: [self mainPage  
>> call: self parent call contactPage] text: 'Contact Us'.].
>>    ].
> Do you mind if I ask what "clearAllDelegates" does?  I found that  
> it is part of Seaside, but didn't see anything that
> really explains what its for..

This is one of the very cool parts of Seaside... the #call: #answer:  
methods. What happens is that you send the #call: message with a  
WAComponent subclass as the argument. The component that was called  
becomes the delegate for the calling component. For all intents and  
purposes, it replaces the calling component until it issues an  
#answer message, then the "control" is returned to the calling  
component. The renderContentOn: method of the top delegate is the one  
that is rendered, all the other delegates in the chain are  
effectively invisible. You can chain as many of these #call:s as you  
want. clearAllDelegates removes the delegate chain, so the root  
component is the one that is rendered again.

I hope this shed a bit of light on the subject, but it may be  
confusing from my description ;)



>> This means that you have to have accessor method for the instance  
>> variables that get initialized on the MyWebApp class so that you  
>> can call "self parent enrollPage" from the MenuArea component. You  
>> could also create convenience methods on your menu page, like:
> Thanks again.. I'll try this out.. I guess I've never gotten into  
> writing web pages in true OO before and am having a hard time
> of it..
>

Try to think of it more like GUI programming on a desktop rather than  
some template based web framework. In a normal web app, pages are  
short lived, but in seaside an object that renders a page stays  
around for your session and can have much greater functionality.

Brian


> -- Rick
>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside