What's the difference and why??

> Hi Rick - let's step back for a sec and talk about a different
> structure....
>
> :)
>
> 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.
>
>
> Then, in MyWebApp>>renderContentOn:
>
> renderContentOn: html
>     html divClass: 'sidebar' with: [html render: menuArea].
>     html divClass: 'contentarea' with: [html render: mainPage].
>
> Then in MenuArea class, you would have a class side method like:
>
> on: aComponent
>     ^ (self new) parent: aComponent
>
> ... back on the instance side (a setter for parent):
> parent: aComponent
>     parent := aComponent
>
> (parent being an instance var)
>
> parent
>     ^ parent
>
> and then:
>
> 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'.].
>    ].
>
> 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:
>
> enrollPage
>     ^ self parent enrollPage
>
>
> Anyway, I hope this gives you a different idea of how you can do some
> things. Feel free to ask any other questions!

> Brian Brown wrote:
>> Hi Rick - let's step back for a sec and talk about a different  
>> structure....
>>
>> :)
>> questions!
> Brian,
>
> Just one more question.. I've got an "about" page that is called as  
> shown directly above (using #call) and it works fine,
> but I'd like for that page to be able to render the contents of the  
> same menu area class (menuArea object from above)
> as the parent object does and am wondering about the best way to do  
> that.  I figure I've got two possible ways to do it
> -- one would be to add an "on: " method to my About class so the  
> parent class can register its instance with the
> aboutPage object at creation time (pros: only one menuArea object),  
> or I can just create another instance of the
> menuArea everytime the About page is pulled up.. Is there another  
> way to do this?  Thanks!
>
> -- Rick

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

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

>> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside