[TYPO3-ect] Controller Architecture Problem - READ THIS FIRST :-)

[Michael Knoll]

Hi there,

all my requirements are perfectly satisfied by the lib_controller. I 
just implemented a doPreActionProcessings() function in my extended 
controller, checked for login-state and overwrite the action if I want 
to display an error message. So everything I wanted to do is possible.

Great job, Elmar! Go on!

Thanks

Mimi




Michael Knoll wrote:
> ... ooops - read first - write later...
> 
> sorry, I just discovered, that there are those two functions mentioned 
> in my second proposal.
> 
> But for me, there is still the problem, that I can't "stopp" running the 
> controller at this point. Should I do something like change the action 
> and implement a "notLoggedInStopControllerAction" - function, which is 
> called, if no log in is available?
> 
> Sorry, for posting so much on nothing... shame on me...
> 
> 'll go to bed now and work on tomorrow...
> 
> Mimi
> 
> 
> 
> Michael Knoll wrote:
>> Hi list,
>>
>> after playing around with the functionality of lib/div, I have the 
>> following problem with the controller class, which I'm not sure how to 
>> cope with the best way.
>>
>> I would like to extend the controller to do some login-status-check 
>> for me, which I want to do with a configuration given in TS.
>>
>> What I would like to do, is extend the controller class 
>> (tx_lib_controller) and overwrite the main method, so that it first 
>> does my status-check and then runs the "standard" controller function. 
>> Now my problem is the fact, that all the setting up of context (like 
>> finding out which action to handle, setting up the parameters in the 
>> controller object and so on) is put in the main function. So for me, 
>> there is only the possibility to overwrite the whole main function and 
>> put my code "in the middle" of it.
>>
>> This is not very beautiful, as every change in the main function of 
>> tx_lib_controller takes the effect of me changing my function again.
>>
>> Wouldn't it better to split the main function into two different 
>> functions, one to set up the context and one to "run the action". With 
>> this design, one could easily extend the controller class and run 
>> "post-context-setting" - "pre-action-running" stuff like my login check.
>>
>> I would suggest a splitting of the functions like the following example:
>>
>> function main(...) {
>>     $this->setContext(...);
>>     return $this->runAction(...);
>> }
>>
>> So the extended class could have a main function like this:
>>
>> function main(...) {
>>     $this->setContext(...);
>>     doSomeClassSpecificStuff(...);
>>     return $this->runAction(...);
>> }
>>
>> There is still some code to be written twice, but not as much as in 
>> the architecture of the code, as it's implemented at the moment.
>>
>> The problem will effect any application that needs a context to be set 
>> but needs some application-specific changes in the controller before 
>> the action is handled.
>>
>> Another possibility would be to use a template pattern here, that 
>> let's you add some hook functions in the initialization of the 
>> controller, like:
>>
>> function main(...) {
>>     $this->doBeforeContextSetting(...);
>>     doContextSettingStuff...
>>     $this->doBeforeRunningAction(....);
>>     return $this->runAction(...);
>> }
>>
>> /* To be overwritten in extending classes */
>> function doBeforeContextSetting(...) {
>>     return true;
>> }
>>
>> /* To be overwritten in extending classes */
>> function doBeforeRunningAction(...) {
>>     return true;
>> }
>>
>> with template methods to be overwritten in the extending controller 
>> classes. But that offers you no possibilty to return from the 
>> controller's main function depending on what happens in the template 
>> functions.
>>
>> At the moment I think it's not very elegant to extend the controller 
>> and get the context-setting-stuff done before you insert your own 
>> functionality.
>>
>> What do you think about?
>>
>> Regards
>>
>> Mimi