Since gii is a module and sometimes the owner application would take more control over it, it would be useful if the DefaultController (system.gii.controlers.DefaultController) would be inherited from Controller instead of CController, like usually the controllers of other modules.
That’s exactly the reason why you’d want to extend Gii 
I think each module should be as independent as possible. So it shouldn’t make assumptions about which Controller class the hosting application provides…
Like I said earlier: extend Gii - make a custom generator.
[size="5"]Click[/size]
What happens is that the default Gii generators generates code for the default generated web application.
Feel totally free to customize both.
Normally, people just create their own Gii extensions.
Well, i particularly thought about "just" the controlling the authorization and authentication of a module.
A module is usually intended to be used as an organic part of different applications, not a kinda standalone app. I think a well-designed module’s access role system have to be customized properly from any owner application.
Subclassing all controllers (even the modules’ ones) from a base app-defined one seems like a good practice to me to tend there. Many extension modules (eg. Dashboard, User, Giix) follow that convention.
I understand the problems (struggling with the same at the moment). I’m not yet sure how I’ll solve them, but one idea was:
In module’s base-controller (derived from CControler), check for a certain app param (maybe “baseAccessRules”), then merge the module specific access rules with those. If the param is not set, use a fallack - in general, I use
class MyModBaseController extends CController {
public function accessRules() {
$appBaseRules = isset(Yii::app()->params['baseAccessRules']) ? Yii::app()->params['baseAccessRules'] : array(
array( 'deny', 'users' => array('?') ),
array( 'deny' ),
);
$modBaseRules = array(
);
return array_merge( $appBaseRules, $modBaseRules );
}
This will redirect guests to the login form and will forbid access to already authenticated users. Every concrete controller of the module extends those rules with a whitellist:
class MyModModelController extends MyModBaseController {
public function accessRules() {
return array_merge(array(
array( 'allow', 'roles' => 'MyModModelManager' ),
), parent::accessRules());
}
So now with this, the module makes no assumptions about classes that must be provided by the hosting application. The only assumption is an appParam. But this can be declared in config without changing the app’s actual code and even if it is not defined, the module will work with a reasonable fallback solution.
To modify this behavior, and to grant admins access to all actions, the app could define in it’s config:
'params' => array(
'baseAccessRules' => array(
array( 'allow', 'roles' => 'admin' ),
array( 'deny', 'users' => array('?') ),
array( 'deny' ),
),
),
yes, using app’s config file is a smart concept, i use the subclassing from the app’s Controller essentially the same way.
Anyway i guess you also feel the point: any modules’ authxxx system should be customized from the owner app without extending the module by a new one