[Seaside] LoginComponent as Subcomponent

seaside_list at objektfabrik.de seaside_list at objektfabrik.de
Thu Oct 5 12:52:53 UTC 2006


Maybe someone can help me...

I have a root component in my app with a banner and toolbar, navigation and working area subcomponents. Toolbar and navigation area change contents dependent on session state, and the working area is where all 
the nice forms for the user are being displayed.

Now I want to have some components to only show up if a user is logged on and has been authenticated. I have found how to do this in a tutorial by Roger Whitney. He suggests using a special session class (which I already do for other reasons) and use the code below to ensure the login component is always being called by the session if no user is logged on:

   user ifNil: [self loginUser].

   ^user := self mainClass new call: SeasideLogin new

(for the full tutorial look here: http://www.eli.sdsu.edu/courses/fall04/cs683/notes/seasideLogin/seasideLogin.html)

My problem is that this code makes the login component (SeasideLogin) the only component in my browser, that replaces the root component.
I'd like to let my current working area component to be replaced by the login component, just as if the current component in the working area had done a call: . 

How can I achieve this? 
I tried the following: 
I added an inst var for the current rootComponent for the session.
I subclassed WARenderLoopMain and overrode #createRoot to not create a new instance of the rootComponent but gets the session's instance and has its working area's subcomponent call: the login component. 
At first, this looks good: the loginComponent only occupied the working area. But the #answer: of the loginComponent does not return to where I thought it should, and the loginComponent stays in the working area forver. If it had been call:ed by the component that was in place before, it would have delegated back.

The only idea I have now is that I could create a new common superclass for all my components that can possibly appear in the working area and implement a #login method that does the call:. But this would mean that subcomponents need to know more about their environment than I think would be good.

Would an #onAnswer: help me? How do others solve this problem?

Thanks for hints


More information about the Seaside mailing list