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

[Brian Brown]

On Mar 14, 2006, at 11:03 AM, Rick Flower wrote:

> Brian Brown wrote:
>> Try thinking of your main entry point (what I referred to as  
>> MyWebApp in the example) as box with dividers in it, and your  
>> other components are the things that fit into those divided  
>> spaces.  So things like mainPage, enrollPage, aboutPage etc. get  
>> rendered into one of those divided spaces, likely the biggest  
>> space. aboutPage, for example, doesn't render a menu. The menu is  
>> rendered as a peer to it in a different "divided space". This  
>> follows what I had put in before by way of example for  
>> MyWebApp>>renderContentOn:
> I can certainly do it that way (hadn't really thought about it that  
> way -- perhaps I'm still in the PHP mindset)
>
>>>
>>> renderContentOn: html
>>>     html divClass: 'sidebar' with: [html render: menuArea].
>>>     html divClass: 'contentarea' with: [html render: mainPage].
>>>
>>
>> the thing that initially gets rendered inside of the div  
>> 'contentarea' get's replaced by the menu calls; mainPage doesn't  
>> render any menus, and when the menu sends the #call: message to  
>> mainPage for say, aboutPage, the menu stuff is still rendered in  
>> the 'sidebar'.
> Yes, but it sounds like I'd have to refactor my code to only show  
> the "current" view in the "content" div.. Initially when the site  
> comes
> up they would see the login pane + MOTD (message of the day) -- if  
> they then click on the "about" link, they'd get different content.
> I initially had it this way but never saw my content for the about  
> page since it also had a renderContentOn: method which was
> getting replaced by the top-level code mentioned above in your code  
> snippet.  Perhaps the best way to keep track of this is
> through the use of some sort of state instance variable.. When the  
> user presses "about", the callback in the menu object sets
> the parent's instance variable to indicate state=about and the top- 
> level code renders the content appropriately by examination of said
> state variable.  I believe only the top level code would need to  
> deal with the state (and the menu object to set the state) and nobody
> else would care.
>

I'm not quite tracking what you did before... the stuff I had written  
would take the click on the about link and tell the component in the  
content div to call the about component. (but first clearing the  
delegate that we talked about in the other thread). I don't  
understand what you mean about your about page not getting rendered.

You have to visualize that what gets rendered for a particular  
browser is the sum of all the VISIBLE components on the screen. So  
for any WAComponent that has #call:d something, only the last link in  
the delegate chain gets rendered. For a given request from a browser,  
you will typically have several "visible" components   being  
rendered.  So you are defining a master component with designated  
"holes" in it, into which you put other components.

And yes, sometimes you create class side #on: methods so you can pass  
in a component that you want to interact with.

At some point, if you want to put up your image and changes file in a  
zip archive somewhere I get to it. :)


Brian



>> Is this making any sense?
> Yes.. I guess my PHP mindset keeps coming back to the foreground  
> and screwing me up once in a while..
>
> Thanks!
>
> -- Rick
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside